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

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

Подход, на который мы будем опираться, называется DFA — Design for Assembly (проектирование для сборки). Набор методов DFA гарантирует возможность сборки компонентов на плате, когда она поступит на монтажный участок, и позволяет отправлять плату в тираж без страха потерять деньги и время.

Современным разработчикам, чтобы совершенствовать профессиональные навыки, требуется постоянно заниматься самообразованием. Как говорила Алиса из небезызвестной книги Льюиса Кэрролла: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее». И это действительно так — останавливаться не стоит.

Один из самых распространённых инструментов самообразования — книги. Сегодня поговорим о полезных для разработчиков С++ изданиях, часть которых — просто must have. Всего в подборке пять вариантов, некоторые из них, вероятно, покажутся читателям необычным выбором. Но все они полезны для программистов. Если у вас есть собственные предпочтения, которые в подборку не попали, пишите о них в комментариях, с удовольствием ознакомимся.

Как пользоваться VS Code в полную силу

Это небольшой туториал о настройке VS Code для работы с python. Здесь вы не увидите каких-то божественных откровений — тут будет просто мой опыт о том, как сделать свою работу/хобби немного комфортнее и почему я пришел именно к такой конфигурации.

• std::mdspan
• std::flat_map
• std::flat_set
• freestanding
• std::print("Hello {}", "world")
• форматированный вывод ranges
• constexpr для bitset, to_chars/from_chars
• std::string::substr() &&
• import std;
• std::start_lifetime_as
• static operator()
• [[assume(x > 0)]];
• 16- и 128-битные float
• std::generator
• и очень много другого

Мой уход из Яндекса, как не потерять мотивацию за полгода подготовки в FAANG и реджект в Google.

Доброго времени суток, друзья!

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

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

Украинский профильный ресурс DOU.UA опубликовал статью о нелегком пути релокации специалиста в США во время пандемии, где он также отвечает на дополнительные вопросы и комментарии.

Адам Леос — Senior Software Engineer в Roku. Пару лет назад он принял решение о релокации и в итоге выбрал своей целью США. Всего за три месяца Адам с нуля собрал все необходимое для подачи на визу О1, но потом в историю вмешалась пандемия. О том, с какими трудностями он столкнулся из-за карантина, как искать работу на американском IT-рынке, как получить большое количество офферов и выторговать самую выгодную компенсацию, разработчик рассказал в интервью DOU.UA

Разработчики часто сталкиваются с необходимостью разработки многопоточных приложений, поэтому вопросы многопоточности требуют детального изучения. Давайте познакомимся с основными терминами, используемыми в источниках информации о многопоточности, рассмотрим задачи и проблемы многопоточности и изучим средства стандартной библиотеки C++, которые помогут создавать многопоточные приложения.

В первых двух статьях цикла мы рассмотрели четыре способа упорядочить доступ к памяти: load-acquire и store-release операции в первой части, барьеры чтения и записи в память — во второй. Теперь пришла очередь познакомиться с полными барьерами памяти, их влиянием на производительность, и примерами использования полных барьеров в ядре Linux.

Рассмотренные ранее примитивы ограничивают возможный порядок исполнения операций с памятью четырьмя различными способами:

• Load-acquire операции выполняются перед последующими чтениями и записями.
• Store-release операции выполняются после предыдущих чтений и записей.
• Барьеры чтения разделяют предыдущие и последующие чтения из памяти.
• Барьеры записи разделяют предыдущие и последующие записи в память.

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

Это ознакомительная статья о языке программирования Rust и его инструментах, с помощью которой я надеюсь привлечь ваше внимание к этому интересному и уникальному языку, созданному чтобы дать ответ на следующие вопросы разработчиков:

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

Цель данной статьи не рассказать о доселе невиданных возможностях Rust (сразу говорю, что тут ничего нового "Растоманы" не найдут), на Хабре вы итак найдете множество интересных статей о внутренностях языка и интересных случаев использования. Моя цель рассказать о том, что он предлагает в качестве решения обозначенных выше проблем, как это будет выглядеть со стороны программиста, и почему это важно.

Для кого она нужна?

1) начинающих реверсеров, знающих особенности обратного проектирования, и желающих изучить такой отладчик как GDB

2) как подсказка тем кто постоянно работает с IDA, Ghidra или любым другим мощным и надежным инструментом, но в силу тех или иных обстоятельств решить задачу проще и быстрее с помощью GDB, и не очень хочется залезать в официальную документацию и снова все вспоминать

Отладка makefile - это что-то из черной магии. К несчастью, не существует такой вещи как makefile отладчик, чтобы изучить ход выполнения конкретного правила или как разворачивается переменная. Большую часть отладки можно выполнить с помощью обычных print’ов и проверкой makefile. Конечно, GNU make немного помогает своими встроенными методами и опциями командной строки. Один из лучших методов отладки makefile это добавить отладочные перехваты (hooks) и использовать техники безопасного программирования, на которые можно будет опереться, когда дела пойдут совсем плохо. Далее представлено несколько основных техник отладки и практик безопасного программирования, которые будут, на мой взгляд, наиболее полезными.

Для написания эффективных и корректных многопоточных приложений очень важно знать какие существуют механизмы синхронизации памяти между потоками исполнения, какие гарантии предоставляют элементы многопоточного программирования, такие как мьютекс, join потока и другие. Особенно это касается модели памяти C++, которая была создана сложной таковой, чтобы обеспечивать оптимальный многопоточный код под множество архитектур процессоров. Кстати, язык программирования Rust, будучи построенным на LLVM, использует модель памяти такую же, как в C++. Поэтому материал в этой статье будет полезен программистам на обоих языках. Но все примеры будут на языке C++. Я буду рассказывать про std::atomic, std::memory_order и на каких трех слонах стоят атомики.