this->notes.

#highload Попытаюсь с умным видом вкинуть инфы про высоконагруженность. Очень важной задачей при разработке высоконагруженных систем является поддержание отказоустойчивости (часто хочется удержать что-то вроде 99.99% аптайма). У нас проверка работоспособности сервисов проверяется довольно понятно: проводятся учения по отключению одного из датацентров. Такие учения бывают внешние (для всей компании) и внутренние (для конкретных сервисов и продуктов). По своему (небогатому) опыту могу сказать, что такие мероприятия очень полезны: вроде на прошлой неделе всё прошло успешно, а сегодня уже проблемы с коннектами в базе, тайминги выросли или на сервисе начинает загораться congestion control. Но рассказать хотелось бы об инструментах Netflix: chaos monkey. Chaos monkey является частью chaos engineering (хотя можно сказать, что стала началом): Chaos engineering is the discipline of experimenting on a distributed system in order to build confidence in the system's capability to withstand turbulent conditions in production. Суть chaos engineering в том, что вы проверяете, как ваша система работает при псевдо-случайных отключениях различных своих частей, что в целом довольно близко к естественным ситуациям, которые часто происходят с высоконагруженными системами. Обычно падения настраиваются, чтобы отключение инстанса происходило в тот момент, когда команда наиболее готова к сражению с падением. "Падать" могут лишь те машинки, которые помечены для этого доступными. Все доступные для "уранивания" машинки делятся на группы. Каждый будний день обезьяна приходит в каждую группу инстансов и бросает монетку (если точнее, то монетка взвешеная), чтобы решить, ронять ли какую-то машинку из этой самой группы. Если она решает, что надо, то шчедулит падение на случайное время в промежутке от 9:00 до 15:00. Каждое приложение/сервис определяет 2 величины, на основе которых бросается монетка: среднее время в рабочих днях между падениями и минимальное время в рабочих днях между падениями. Из минусов можно отметить: - для chaos monkey необходимы spinnaker (система развёртывания в нетфликсе) и mysql; - генерирует только псевдослучайные падения конкретного инстанса приложения/сервиса, в то время как разнообразие проблем в реальной жизни гораздо шире; - работу chaos monkey нельзя просто так прервать. Если что-то пойдёт не так, остаётся только сражаться. В какой-то момент одного инструмента стало не хватать, потому появилась simian army (которая, тем не менее, уже не поддерживается). Simian army включает в себя ещё три основных инструмента: 1. Janitor monkey или сегодня swabbie -- аналог сборщика мусора для облачной экосистемы. 2. Conformity monkey проверял соответствие инстансов некоторым предефайненым правилам. В случае несоблюдения правил, инстанс отключался. Сейчас это часть spinnaker. 3. Security monkey проверял инстансы на различные дыры в безопасности. и ещё несколько, которые были депрекейтнуты сильно раньше или не опубликованы: 4. Chaos gorilla, который симулировал отключение одной из 25 зон инфраструктуры AWS (т.е. отключение огромной части всех инстансов). 5. Chaos kong -- аналог прошлого инструмента, но симулирующий отключение меньших частей инфраструктуры. 6. Latency monkey -- тулза, увеличивающая тайминги ответов некоторых ручек в сервисах. 7. Doctor monkey -- инструмент, мониторящий состояние инстансов. Если инстанс "заболел" (пятисотит, выросли тайминги или кушает много cpu), doctor убирает его из приложения. 8. 10-18 monkey (i.e. l10n-i18n) проверяет работу сервисов, которые работают в различных географических зонах. Чекаются проблемы связанные с локализацией и всем что около.

#c #cpp Попалась довольно сомнительная статья на хабре про редкие возможности в С. Учитывая половину списка, не очень понятно, что такое редкие возможности в понимании автора. Не предлагаю вам её читать, чтобы не тратить время. Остановлюсь только на самых интересных моментах и прокомментирую/добавлю немного информации. 1. Конкатенация строк времени компиляции. Думаю, вы тоже видели какой-то подобный код: std::string very_long_string = "This is first part of long string." "And this is second"; Никаких плюсов и функций конкатенации: компилятор сделает это одной строкой сам. Используя такое поведение можно реализовать интересный макрос: #define LOG(exp) std::cout << "Result of " #exp "=" << exp; int x = 12; LOG(x*5); Результатом будет "Result of x*5=60". 2. Препроцессорная склейка строк. Как вы думаете, будет ли инкремент в следующем коде? int inc(int x) { // doing increment\ x++; return x; } Вопрос в том, что произойдёт раньше: конкатенация строк, разбитых через \, или замена комментария на пробельные символы? Легко можно убедиться, что x++ станет частью комментария, то есть строки конкатенируются раньше. Я как-то смотрел замечательную лекцию по тулчейну, где пояснялся этот момент и думал "ну разве можно так набагать", а недавно мне рассказали, что обнаружили подобное в проде. Забавно. 3. Функции в стиле K&R. Не знал, что такая возможность раньше была в C. Суть заключается в том, что вы объявляете функцию следующим образом: int foo(s, f, b) char* s; float f; struct Baz * b; { return 5; } в то время как сегодня она выглядела бы более привычно: int foo(char* s, float f, struct Baz * b) { return 5; } 4. tmpfile. В статье конечно речь идёт и сишной функции, однако есть аналог std::tmpfile (который тем не менее ничем не отличается). Автор не приводит каких-то полезных применений временных файлов. Мне когда-то было полезно при написании внешней сортировки (правда, там было использование std::tmpnam, но сути не меняет), а ещё, если внимательно посмотреть на то, что делает ваш компилятор при билде программы (например --verbose для g++), то можно увидеть, что компилятор создаёт некоторое кол-во временных файлов, которые можно даже попросить его не удалять. 5. Отрицательные индексы. Делается такое довольно просто: int* arr = new int[100] + 50; Теперь можно обращаться по индексу в обе стороны. Только, как и всегда, стоит быть осторожным с границами и очищением памяти : ) 6. std::new_handler. В C++ есть такое понятие как new_handler (не новый обработчик, а обработчик оператора new). В случае, если new не может выделить необходимое количество памяти, он вызывает свой обработчик в надежде, что тот разрулит ситуацию: сделает дефрагментацию, что-то освободит, переназначит обработчик или что-нибудь ещё. В случае повторного неуспеха обработчик будет вызван ещё раз, то есть такая программа вполне приводит к бесконечной рекурсии: void f() {} int main() { std::set_new_handler(f); int* p = new int[1000000000000]; }

#common The Little Things: Comparing Floating Point Numbers. codingnest.com/the-little-things-comparing-floating-point-numbers/

#cpp #proposals Пачка новых предложений за январь. 1. У бумаги про std::hive уже 19 ревизий. И тут ещё появилась просьба вернуть это предложение в 23й стандарт. Оч интересно, как это предложение летает туда-сюда. Мне почему-то забавно. 2. Пары и туплы очень похожие типы, ведь первое просто частный случай второго. Туплы могут быть сконструированы из пар, но не наоборот. Такое положение наводит на мысли, что std::pair немного избыточен. Удалять его конечно никто не будет, но туплам можно добавить некоторые возможности пар, чтобы последние использовались реже. Proposal. 3. Из C делают современный язык, хех. Но местами выглядит это конечно мда: Basic lambdas for C, Improve type generic programming. 4. Ослабление ограничений для constexpr. На самом деле тут ничего капитального. Просто какие-то мелочи. 5. std::breakpoint для остановки при выполнении в дебаге. Честно говоря, не очень понимаю, зачем тащить это в язык. Дебагеры хорошо справляются. 6. std::is_debuger_present для понимания, отлаживается ли сейчас программа. Вот это уже что-то полезное. Довольно часто приходилось пихать вывод только для отладки. 7. Сделать move_iterator<T*> random_access итератором. Это поможет выполнять некоторые операции с ренджами эффективнее. 8. Более строгое требование для атрибута [[assume(...)]].

#cpp Помоги компилятору помочь тебе. Автор рассказывает о флагах компиляции, что они делают, и почему стоит их использовать в своих проектах. habr.com/ru/post/490850/

#cpp #common 1. Некоторые способы определения битовых флагов. m-peko.github.io/craft-cpp/posts/different-ways-to-define-binary-flags/ 2. How to collapse nested switch statements. www.fluentcpp.com/2017/06/27/how-to-collapse-nested-switch-statements/ 3. How to choose good names. www.fluentcpp.com/2017/01/30/how-to-choose-good-names/ 4. A class without copy constructor. quuxplusone.github.io/blog/2021/09/17/a-class-without-a-copy-constructor/ 5. About (in)valid objects. arne-mertz.de/2021/09/isvalid-establish-invariants-avoid-zombies/

#algo Довольно приятный плейлист про не очень стандартные алгоритмы, которые ещё и хорошо поясняются. www.youtube.com/playlist?list=PLc82OEDeni8SGp5CX8Ey1PdUcoi8Jh1Q_

#cpp Элементы функционального программирования в C++. [из Википедии] Частичное применение - возможность в ряде языков программирования зафиксировать часть аргументов многоместной функции и создать другую функцию. habr.com/ru/post/313370/ Композиции отображений. habr.com/ru/post/328624/

#cpp Динамический неоднородный плотно упакованный контейнер. habr.com/ru/post/302372/

#cpp [видео] CppCon 2019. Timur Doumler. Type punning in modern C++. Автор рассказывает об алиасинге типов и strict alias rule, выравнивании, неопределённом поведении и как его избежать. youtube.com/watch?v=_qzMpk-22cc

#cpp Метапрограммирование в C++ и русская литература: через страдания к просветлению. habr.com/ru/article/448466/

#cpp Рефлексия в C++Next на практике. habr.com/ru/post/598981/

#cpp Краткий ликбез (наверное уже последний) по основным нововведениям в С++20. cppstories.com/2022/20-smaller-cpp20-features/