Температура на матрице WS2812B

Температура на матрице WS2812B - простой проект для вывода температуры с датчика AHT21 на матрицу WS2812B 8x8 светодиодов.
Типизированный язык программирования
Температура на матрице WS2812B - простой проект для вывода температуры с датчика AHT21 на матрицу WS2812B 8x8 светодиодов.
В процессе изучения бекэнда, как нового для меня направления в программировании, я столкнулся с необходимостью оптимизации управления соединениями. Поискав в интернете существующие решения для библиотеки pqxx
(C++ API для PostgreSQL), я обнаружил, что хотя они и выполняют свою задачу, ни одно из них не соответствовало моим требованиям.
Это побудило меня разработать собственную реализацию пула соединений, которая была бы не только эффективной и масштабируемой, но и предоставляла бы удобный API для работы с транзакциями. Моя цель - создать решение, которое могло бы быть легко интегрировано в любой проект, использующий pqxx
, обеспечивая при этом более высокую производительность и стабильность.
В данной статье я хочу поделиться процессом разработки и обсудить некоторые моменты реализации.
Так повелось в мире, что время от времени необходимо проводить исследования безопасности драйверов и прошивок. Одним из способов исследования является — фаззинг (Fuzzing). Не будем останавливаться на описании самого процесса фаззинга, для этого есть эта статья, отметим только, что в основном его используют для исследования прикладных приложений. И тут возникает вопрос: как профаззить прошивку, в частности прошивку UEFI? Здесь будет рассказано об одном из способов с использованием программного эмулятора EDKII, чтобы проводить фаззинг без развертывания аппаратных стендов. И что важно, все это сделаем в Windows.
Всем маткульт-привет! В этой статье мы продолжаем и заканчиваем написание консольного инженерного калькулятора.
В прошлой части мы научились разбивать исходное математическое выражение формата (log2(18)/3.14)*sqrt(0.11^(-3)/0.02)
на токены. На выходе мы получаем массив токенов, каждый их которых содержит информацию о типе (оператор, скобка, число, ...) и об ассоциативности, если он таковую имеет.
Теперь мы хотим привести выражение к виду обратной польской записи (RPN), чтобы затем удобно его посчитать. Это нам позволяет сделать изобретенный Эдсгером Дейкстрой алгоритм сортировочной станции.
Почему с некоторыми монстрами интересно играть? Графика тут конечно играет определенную роль вначале, красивая картинка радует глаз, а музыка берет за душу. Но если враг тупит, если поведение читается на раз-два, то внимание игрока начинает подмечать ошибки в целом, быстро разрушая общее впечатление, даже графоний не поможет, так устроено внимание человека. Среднее время удержания внимания на элементе игровой механике или поведении составляет не больше пяти минут. Дизайнеры игр об этом знают и стараются в пределах этого времени переключать внимание игрока на что-то другое. Вернемся к AI монстров, это же правило действует и здесь, если в течение пяти минут, NPC не показывает новых приемов в бою или поведении, то игроки считают его "тупым", много тупых и однотипных в поведении монстров вызывают только раздражение. Можно много говорить о быстром развитие ИИ общего назначения, увидеть его применение в играх, выходящим за рамки общения и диалогов вряд-ли получится в этом десятилетии. Поэтому нам остается применять проверенные временем поведенческие деревья (BT, Behavior Tree, GOAP), но тем не менее очень мощные и нейронную сеть общего назначения на печеньках и кофе.
В сегодняшней публикации мы поговорим о новом новшестве в мире C++ - операторе "спейсшип" (spaceship), он же тройное сравнение.
По катом много нудных подробностей.
Эта статья обсуждалась на Hacker News.
В течение минувшего года я шлифовал мой подход к выделению регионов. Практика показывает, что это эффективный, простой и быстрый подход; обычно его используют в качестве средства для сборки мусора без издержек. В зависимости от того, что нам требуется, в аллокаторе может быть всего 7–25 строк кода — идеально для случаев, когда мы работаем без среды исполнения. Теперь, когда я окончательно сформулировал ключевые аспекты моего подхода, самое время их задокументировать и рассказать вам о том, что мне удалось выучить. Определённо, это не единственный возможный подход к выделению регионов. Я просто расскажу вам о приёмах, которые сам выработал для упрощения программ и искоренения ошибок.
Регион (арена) — это буфер памяти и смещение до этого буфера. Изначально это смещение равно нулю. Чтобы выделить объект, нужно взять указатель на него с заданным смещением, увеличить смещение на размер объекта, а затем вернуть указатель. Этим дело не ограничивается — например, нужно обеспечить выравнивание и доступность. До этого мы ещё дойдём. Объекты не высвобождаются каждый по отдельности. Напротив, сразу высвобождаются целые группы ранее выделенных объектов, и смещение откатывается к более раннему значению. Когда не предусмотрены собственные времена жизни для отдельных объектов, деструкторы писать также не требуется, а вашим программам не приходится прямо во время выполнения обходить структуры данных и убирать ненужные. Кроме того, больше можно не беспокоиться об утечках памяти.
В этой простенькой статье расскажу о проблемах, с которыми я столкнулся при изучении CMake, и о их решениях. Если кратко, то с помощью функции из репозитория, а также замечанию от пользователя Sazonov, у меня получилось сделать древовидную структуру как в проводнике.
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
В одном недавнем подкасте о том, кто сейчас главный в Rust, вновь всплыл вопрос о том, кому быть BDFL (великодушным пожизненным диктатором), и Джереми Соллер сказал (это был чемпионский заход на приз «за преуменьшение века»): «Я считаю, Грейдон забраковал бы некоторые вещи, которые всем нам сейчас нравятся». Этим он вторит другой дискуссии на reddit, в которой мне напомнили, что я собирался как-нибудь расписать, каким образом «я сделал бы всё по-другому». Вероятно, это бы крайне не понравилось всем причастным, и эти идеи далеко бы не распространились.
Ну и ну. Я понял, что следующий момент не вполне очевиден и он, пожалуй, заостряет вопрос, «а действительно ли в проекте нужен BDFL». Так вот, озвучу его: Rust Нашего Времени далеко, далеко отстоит от Rust Моей Мечты. Главное, не поймите меня неправильно: мне нравится, что у нас получилось. Получилось отлично. Я воодушевлён, что теперь есть столь жизнеспособная альтернатива C++, в особенности такая, которую другие люди уже начинают воспринимать как норму, как реальный вариант для повседневной работы. Я пользуюсь Rust и очень доволен, что могу отдавать ему предпочтение перед C++. Но!
Я столько всего сделал бы в Rust по-другому, если бы всё это время «отвечал» за его развитие.
Результаты ежегодного опроса Annual C++ Developer Survey "Lite" за 2023 год наконец опубликованы, и мы можем почерпнуть из них ценную информацию об опыте C++ разработчиков. Одной из самых интересных целей этого опроса является выявление ряда болевых точек, с которыми приходится иметь дело C++ разработчикам.
В этой статье мы рассмотрим несколько узких мест в разработке на C++, на которые больше всего жаловались опрошенные разработчики.
В данной статье хочу немного рассказать о небольшом исследовании реализации expected, в которой используется стирание типа ошибки.
Если вы занимаетесь обучением крупных современных нейросетей, эта статья будет вам не совсем в тему, ведь у A100 скорость в сто раз выше (156 терафлопсов).
Так что же интересного в этих полутора терафлопсах?
Мы говорим не о мощных ускорителях или тензорных ядрах графических процессоров, а лишь о настоящей производительности линейной алгебры, которая отстоит от регистров процессора на один цикл.
В настоящий момент в промышленности активно внедряется высокотехнологичная стратегия развития, называемая индустрией 4.0, которая предполагает активное внедрение информационных технологий в промышленное производство, а также масштабную автоматизацию бизнес процессов и использование систем искусственного интеллекта. Перспективным подходом к построению гибких систем управления для автоматизированных систем, разрабатываемых для индустрии 4.0, является использование языков программирования стандарта IEC 61499.
Автоматизация производственных процессов помимо очевидных преимуществ имеет и ряд сложностей. Одной из проблем является риск подвергнуться кибератакам. Возможным решением является разработка защищенной реализации для среды исполнения IEC 61499 для KasperskyOS. Для этого требуется реализовать киберимунную систему управления путем портирования среды исполнения IEC 61499 Eclipse 4diac forte на операционную систему KasperskyOS.
Поводом для написания статьи послужило не очень приятное для меня событие: модератор Хабра убрал теги – «С++» и «Параллельное программирование» из моей крайней статьи [1]. Этому предшествовало сообщение пользователя, который по его словам не заметил в статье ни С++, ни параллелизма и поспешил об этом известить весь свет. На самом деле он, скорее всего, просмотрел статью по диагонали и попросту "не врубился". Другим объяснить сей казус сложно. Я объяснил причины его заблуждения, но это не было принято во внимание. В ответ – тишина и, более того, пошли у него на поводу.
А до этого, но тоже в контексте рассматриваемой статьи (теперь все это складывается в один пазл), произошло еще одно событие. Другой пользователь, решивший, видимо, поддержать автора, выразил благодарность, но допустил не очень лестные высказывания в адрес специалистов Бауманки. Не то, чтобы я с ним был во всем согласен, но поскольку на асфальте розы не растут, то в чем-то он был все же прав.
Но дело даже не в содержании постов. Если раньше управлять спорными постами доверялось автору, то теперь модератор решил взять на себя это право. Может, у нас месячник усиленной модерации? Но только в чем причины столь сильного недоверия автору? Ведь, модератор явно не очень вникал в суть проблемы и причины появления подобных постов. Логично было бы предоставить, как и ранее, автору решать вопросы, связанные с содержанием его же статей. Последнее сообщение, хотя и содержало критику, но в целом не нарушало правила сообщества. Хотя, обобщать на всю Бауманку, конечно, не стоило бы.
Это почти полная копия моей статьи для внутреннего форума предприятия, где я работаю. Я решил, что эта информация может быть полезна широкому кругу людей, особенно для тех, кто никогда не работал с CAN. В статье описана пошаговая настройка FDCAN в cubeMx, а каждый шаг достаточно подробно описан.
Продолжаю свою мини-серию статей "Как Я", созданную поддержать начинающих соискателей. Сегодня расскажу как проходила стажировка и немного о внутренней кухне Яндекса. Много информации не будет (NDA), но все равно попытаюсь рассказать исчерпывающе. Итак, погнали.
Получение имени типа, не важно это структура или перечисление, в C++ — проблема. То, что тривиально известно компилятору на этапе парсинга исходников, не получится перевести в человеко-читаемый вид в рантайме. Можно использовать std::type_info::name, который не является переносимым решением, потому что зависит от реализации манглинга в компиляторе. Некоторые компиляторы (например, MSVC, IBM, Oracle) создают "удобное" имя типа, а вот gcc и clang, возвращают искаженное имя, котороe можно преобразовать в удобочитаемую форму с помощью дополнительных функций, например abi::__cxa_demangle. Чтобы вся эта магия работала нужно подключить RTTI, который тоже не всегда доступен, а иногда и вообще-то вреден, потому что сжирает драгоценную производительность, но можно сделать по другому.
Привет Хабр!
В этой статье будет разобрана работа Unreal Header tool, рефлексии, и немного затронем VM.
В первой статье рассказали, почему нам потребовалась автоматическая кодогенерация свифтового интерфейса для C++ в Mobile SDK. Описали инструменты, которые есть в нашем распоряжении, и сделали вывод: лучший промежуточный слой для преобразования на сегодняшний день — это C.
Во второй части рассказываем о собственном инструменте, который поддерживает и Swift, и Kotlin — мы называем его Codegen (да :)).