В рамках микросервисной архитектуры достаточно легко делать «реактивные» сервисы: к вам приходит событие или вызов HTTP-метода, и в ответ на это происходит какое-то действие. Однако бывают более сложные сценарии, когда надо собрать некоторое количество информации или событий прежде, чем что-то делать. В таком случае нужен пайплайн — механизм организации сложных правил обработки событий. 

Недавно нам пришлось организовать пайплайн с использованием интересных С++-трюков. О них я и расскажу в статье. 

— Как хранить в одном контейнере разные типы и использовать тип в качестве ключа контейнера 

— Как средствами метапрограммирования удобно сериализовать и десериализовать разнотипные объекты 

— Как сделать универсальный запускатель функций, который будет запускать любую функцию и сам искать, откуда «добыть» эти аргументы 

— И главное, как сделать интерфейс для написания пайплайна обработки события — удобный и полностью изолированный от инфраструктуры

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

Наш основной проект (видео мессенджер) использовал WTL для Windows и GTKmm для Linux. Поддержки мака не было. Огромной неприятностью было тащить два идентичных клиента, которые, по идее, должны делать все строго одно и тоже. Разумеется, это никогда не получалось. От мысли что надо бы сделать ещё один нативный клиент для мака начинался нервный тик...

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

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

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

В 2021 году видимо Гугл работал плохо или звёзды так сошлись, но не нашлось ничего стоящего. Все что попадалось - основанные на рендеринге html проекты и обертка над wxWidgets. Сейчас то мы знаем про lvgl, да...

wxWidgets не плох, но хотелось своего рисования, без окошек под кнопки, поля ввода и списки, boost/bsd подобной лицензией, максимально лаконичной, и в идеале работающей от Windows XP / CentOS 6 на стандартном GDI / X11 до Vulcan на современных машинах.

В итоге, все же было принято волевое решение сделать минимальный UI фреймворк для этого проекта, и сразу выпускать его в Open Source под лицензией boost. 

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

Многие пытливые умы на протяжении десятилетий задавались вопросом: как же реализован std::tuple, как мне реализовать свой тупль (кортеж)? [1]

И немало было дано ответов на такие вопросы и написано статей ([2]). Однако я берусь утверждать, что все они имеют один фатальный недостаток! Конкретнее, они все рассматривают в основном лишь один (и при этом неэффективный) способ реализации: с помощью множественного наследования или рекурсивного инстанцирования, имеющий в свой очередь множество своих недостатков, главный из которых — неэффективное использование памяти.

В то время как современный C++ позволяет реализовать тупль гораздо проще (без обилия шаблоноты) и эффективнее.

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

Столкнувшись много раз подряд с тем, что найти что-то толковое довольно непросто, я решил попробовать распутать это узел и предложить для русскоязычных читателей свой справочник классных библиотек на С++. Я исходил из этого источника. Это очень многогранный и объемный список библиотек языка С++, но, скажем так, у меня были к нему вопросы. Потому я сделал перевод, затем значительно улучшил его в плане содержания (далее объясню, как, почему и зачем). На выходе получилось около 1000 библиотек. Как в сказке). Они, конечно, не покрывают все возможные задачи и предметные области, но поверьте, они затрагивают действительно многое.

Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

Почему тормозит я вам не скажу: возможно разработчики, которые делали её (на не самом новом движке, надо сказать) просто делали игру и не задумывались о рядовых игроках, которые сидят на пятилетнем железе, хотя даже пятилетнее железо уделывает приставки текущего поколения. Возможно это другая причина - когда твоя рабочая машина с 64 гибайтами оперативки и 4080 на борту тянет редактор, то беспокоиться об игроках можно начинать после патча первого дня.

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

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

Меня зовут Игорь, и я Unity Developer. В этой статье хотел бы показать
новый архитектурный паттерн, который внезапно открыл для себя в разработке игр.

Особенность паттерна Entity-State-Behaviour заключается в том, что ваш игровой объект представляет собой Entity, которая состоит из набора данных (State) и логики (Behaviour). За счет жесткого разделения данных и логики, разработчик может легко разрабатывать новые взаимодействия между игровыми объектами, системами и AI и подключать их в процессе выполнения программы...

Квантовая электродинамика (далее КЭД), любимое, но капризное дитя нерелятивистской квантовой механики и специальной теории относительности — весьма непростая физическая теория с зубодробительным математическим аппаратом. Но, в отличие от многих других сложных теорий, в её инструментарии есть одна небольшая и сравнительно обособленная часть, допускающая примитивную, но наглядную трактовку. Я имею в виду так называемые «диаграммы Фейнмана». Cегодня непросто написать статью по квантовой теории поля, не начертив нескольких таких диаграмм, а в некоторых работах они встречаются чаще, чем знаки элементарной арифметики. Как следует из названия, изобрёл эти диаграммы выдающийся американский физик Ричард Фейнман. Сделал он это в конце 1940-х годов для графического описания некоторых математических выражений, возникающих в КЭД. Сразу оговорюсь: разумеется, вычислять диаграммы Фейнмана, за исключением нескольких самых примитивных, очень непросто. За каждой из них стоит строго определённое математическое выражение, обычно весьма сложное. Но при этом у них есть замечательное свойство — они допускают простую качественную словесную интерпретацию и помогают понять некоторые основополагающие идеи, лежащие в основе современной квантовой теории. Идеи эти скорее непривычны, чем сложны и, как мне кажется, в них вполне может на базовом уровне разобраться даже успевающий школьник.

Про эти диаграммы и содержащиеся в них идеи я и хочу рассказать. При этом никаких формул в тексте не будет вообще — только слова и картинки.

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

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

Десять лет назад я писал пару статей - Как загрузить последний Office с сайта Microsoft без всякого App-V / Хабр (habr.com) и Как загрузить Microsoft Office 16 с сайта Microsoft / Хабр (habr.com), при помощи на тот момент еще мало кому известным Office Deployment Tool.

Время бежит стремительно, за Office 2016 выходит Office 2019, Office 2021, и вот сейчас подошло время для Office 2024. Что ж, посмотрим, что поменялось в плане загрузки, установки и активации продукта за десять лет.

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

Microsoft давно перешел на систему распространения продуктов семейства Office по разным, так называемым, "каналам" (channels), в зависимости от того как часто вы хотите получать нововведения и обновления.

Ключевым отличием в текущей загрузке и установке Office от того, что было актуально во времена Office 2016, является то, что вы должны определить, каким каналом распространения вы собираетесь пользоваться, - то есть с какого канала собираетесь устанвливать сам продукт. Тем, кто хотел бы подробно изучить разные каналы распространения я предложу почитать первоисточник - Обновления Office - Office release notes | Microsoft Learn. Остальным кратко резюмирую - Microsoft сейчас предпочитает всем продать подписку на Microsoft 365 (то, что ранее называлось Office 365), с регулярно обновляемыми возможностями в течении так называемой Современной политики жизненного цикла. По этой же современной политике распространяется пользовательские (коробочные, ретейл) версии Office 2021. Office 2021, например, поддерживается лишь до 13 октября 2026. А более старые версии следуют, так называемой политике фиксированного жизненного цикла, в рамках которой Office 2016 и Office 2019 поддерживаются лишь до 14 октября 2025. В целом, они не перестанут работать после, однако, перестанут обновляться. И у тех из вас, кто пользуется почтовыми сервисами на базе Microsoft Outlook.com или Office365, а возможно и пользователям Microsoft Exchange, с обновлениями выпущенными после 14 октября 2025 уже пора призадуматься об обновлении.

Замечания о математике, алгоритмах и методах, применяемых при компьютерной симуляции флюидов (например, огня и дыма) в режиме реального времени.

Исходный код к этой статье выложен на GitHub.

Огонь как явление очень интересен с точки зрения компьютерной графики. Раньше огонь было принято имитировать. Например, в фильме «Властелин колец» Питера Джексона для изображения огня использовались спрайты с огромным количеством дыма (на тот момент симуляция флюидов обходилась слишком дорого, даже при бюджете блокбастера). Когда требовалось моделировать огонь в режиме реального времени, например, в видеоиграх, использовались почти исключительно нефизические подходы.

Часть 1: Реализация шаблона Entity-Component-System на C++

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

Кроме вакансий для стажёров я иногда случайно нажимал на объявления о вакансиях «сеньор-разработчика». Помню, больше всего меня поражало то, что первой строкой шло требование определённого количества лет работы: «Эта должность требует 5+ лет опыта».

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

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

• С опытом программирование не становится намного проще, о «проще пареной репы» можно только мечтать.

• Написание кода для множества «больших проектов» — это не только неинтересное, но и опасное занятие, гораздо менее увлекательное, чем решение алгоритмических задач в LeetCode.

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

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

Хотел написать продолжение к статье Что почитать игровому программисту? про использование С++ в игровых движках, но размышления свернули куда-то не туда.

Завороженно смотрю как и какими темпами идет развитие языка в последние годы, и понимаю, что получить и особенно применить возможности С++20/3 в разработке игр и движков получится хорошо, если с опозданием лет эдак в пять, как раз на следующее поколение консолей, если вообще получится. Сейчас плюсы в игрострое зависли где-то между 14 и 17 стандартом, Сони только-только выкатила свою версию компилятора с полной поддержкой 17 стандарта, а учитывая реактивность игровых студий в изменении кор пайплайнов, что-то новое начнут только в новых проектах. Менять коня, т.е. компилятор посреди разработки игры равносильно стрельбе не только по ногам себе, но и соседям программистам: работает - не чини.

Если смена компилятора и стандарта не даст гарантированного прироста скорости работы больше 5%, то бюджет и людей я не одобрю. (с)

Знакомство с кодовой базой больших движков дает понимание уровня и объёмов кода в продакшене и в тулзах, и ситуация вырисовывается такая, что эти объемы стали в индустрии, что называется "too big to fall", т.е. написать что-то новое, уровня движков вроде Unity/Unreal/Dagor на другом языке, будь он хоть в тысячу раз безопаснее и в десять раз быстрее не получится, но попытки конечно делаются. И чем дальше продолжается поддержка существующих проектов на плюсах, тем меньше возможности выбора остается.

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

При разработке приложений рано или поздно наступает момент, когда заниматься развёртыванием вручную становится затратно и неудобно. Как следствие на помощь приходит автоматизация этого процесса с помощью специально настроенных пайплайнов непрерывной интеграции и непрерывной доставки (Continuous Integration & Continuous Delivery — CI/CD). Для разных систем управления репозиториями исходного кода существуют свои способы настройки CI/CD.

В этой статье мы рассмотрим, как использовать GitLab для организации автоматической сборки и деплоя приложения в кластер Kubernetes. Сам кластер работает под управлением Deckhouse Kubernetes Platform, а автоматизировать процесс будем с помощью werf — Open Source CLI-утилиты, организующей полный цикл доставки приложения в Kubernetes и использующей Git как единый источник истины для состояния приложения, развёрнутого в кластере.

Уже продолжительное время я размышляю над паттерном RxPM и даже успешно применяю его в «продакшене». Я планировал сначала выступить с этой темой на Mobius, но программный комитет отказал, поэтому публикую статью сейчас, чтобы поделиться с Android-сообществом своим видением нового паттерна.

Все знакомы с MVP и MVVM, но мало кто знает, что MVVM является логическим развитием паттерна Presentation Model. Ведь единственное отличие MVVM от PM – это автоматическое связывание данных (databinding).

В этой статье речь пойдет о паттерне Presentation Model с реактивной реализацией биндинга. Некоторые ошибочно называют его RxMVVM, но корректно будет называть его RxPM, потому что это модификация шаблона Presentation Model.

Этот паттерн удобно использовать в проектах с Rx, так как он позволяет сделать приложение по-настоящему реактивным. Кроме того, он не имеет многих проблем других паттернов. На диаграмме ниже представлены различные варианты и классификации шаблонов представления:

От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.

Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

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

После прочтения этого поста вы будете знать, как B-дерево упорядочивает данные и выполняет поисковые запросы.