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

Многие ругают CMake, и часто заслуженно, но если разобраться, то не всё так плохо, а в последнее время очень даже неплохо, и направление развития вполне позитивное.

В данной заметке я хочу рассказать, как достаточно просто организовать заголовочную библиотеку на языке C++ в системе CMake, чтобы получить следующую функциональность:

1. Сборку;
2. Автозапуск тестов;
3. Замер покрытия кода;
4. Установку;
5. Автодокументирование;
6. Генерацию онлайн-песочницы;
7. Статический анализ.

Кто и так разбирается в плюсах и си-мейке может просто скачать шаблон проекта и начать им пользоваться.

Операционных систем без уязвимостей не бывает — вопрос лишь в том, как эффективно разработчики их выявляют и закрывают. Наша ОС Astra Linux Special Edition здесь не исключение: мы постоянно проверяем и тестируем код на ошибки, нарушения логики, прочие баги и оперативно их устраняем. Иначе бы ФСТЭК России вряд ли сертифицировала Astra Linux на обработку данных, составляющих гостайну. Но о сертификации мы поговорим подробней в другом посте. А в этом расскажем о том, как организована работа над уязвимостями Astra Linux и взаимодействие с отечественным банком данных угроз безопасности информации.


Фото: Leonhard Foeger/Reuters

Перевели новую порцию слайдов. Права доступа в Unix, файловые дескрипторы, потоки, магия proc. И на закуску пара советов о том, как общаться, когда ты не согласен. А вдруг пригодятся =)

История встречи статического анализатора PVS-Studio с кодом операционной системы Haiku уходит в далёкий 2015-й год. Это был интереснейший эксперимент и полезный опыт для команд обоих проектов. Почему эксперимент? Анализатора для Linux тогда не было и не будет ещё полтора года. Но труды энтузиастов нашей команды были вознаграждены: мы познакомились с разработчиками Haiku и повысили качество кода, пополнили базу редкими ошибками программистов и доработали анализатор. Сейчас проверить код Haiku на наличие ошибок можно легко и быстро.

Здравствуйте, коллеги.

Сегодня на ваш суд предлагается перевод статьи Тугберка Угурлу (Tugberk Ugurlu), который взялся в сравнительно небольшом объеме изложить принципы проектирования современных софтверных систем. Вот что автор сообщает о себе в сухом остатке:


Поскольку решительно невозможно охватить в хабростатье такую колоссальную тему, как архитектурные паттерны + паттерны проектирования по состоянию на 2019 год, рекомендуем не только сам текст господина Уруглу, но и многочисленные ссылки, которые он в нем любезно расставил. Если вам понравится — опубликуем и более узкоспециальный текст о проектировании распределенных систем.

На этой неделе я начал работать над своим движком для игры Vagabond и приступил к реализации шаблона entity-component-system.

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

Введение

Мотивация

Я не буду рассказывать о преимуществах ECS перед объектно-ориентированным подходом, потому что с этим хорошо справились многие люди до меня. Одним из первых про ECS рассказал на GDC 2002 Скотт Билас. Среди других знаменитых введений в тему можно назвать Evolve Your Hierarchy Майка Уэста и главу Components из потрясающей книги Game Programming Patterns Роберта Нистрома.

Вкратце скажу, что задача ECS — создание ориентированного на обработку данных подхода к игровым сущностям и удобное разделение данных и логики. Сущности (Entities) составляются из компонентов, содержащих данные. А системы, содержащие логику, обрабатывают эти компоненты.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Timer interrupts" автора E.

Предисловие

Плата Arduino позволяет быстро и минимальными средствами решить самые разные задачи. Но там где нужны произвольные интервалы времени (периодический опрос датчиков, высокоточные ШИМ сигналы, импульсы большой длительности) стандартные библиотечные функции задержки не удобны. На время их действия скетч приостанавливается и управлять им становится невозможно.

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

Это давно назревшая статья об обучении с подкреплением Reinforcement Learning (RL). RL – крутая тема!

Вы, возможно, знаете, что компьютеры теперь могут автоматически учиться играть в игры ATARI (получая на вход сырые игровые пиксели!). Они бьют чемпионов мира в игру Го, виртуальные четвероногие учатся бегать и прыгать, а роботы учатся выполнять сложные задачи манипуляции, которые бросают вызов явному программированию. Оказывается, что все эти достижения не обходятся без RL. Я также заинтересовался RL в течение прошлого года: я работал с книгой Ричарда Саттона (прим.пер.: ссылка заменена), читал курс Дэвида Сильвера, смотрел лекции Джона Шульмана, написал библиотеку RL на Javascript, летом проходил практику в DeepMind, работая в группе DeepRL, и совсем недавно — в разработке OpenAI Gym, – нового инструментария RL. Так что я, конечно, был на этой волне, по крайней мере, год, но до сих пор не удосужился написать заметку о том, почему RL имеет большое значение, о чем он, как все это развивается.


Примеры использования Deep Q-Learning. Слева направо: нейросеть играет в ATARI, нейросеть играет в AlphaGo, робот складывает Лего, виртуальный четвероногий бегает по виртуальным препятствиям.

Я уже сбился со счёта часов, которые я потратил на то, чтобы сделать “небольшую коробочку” и вдруг я поймал себя на мысли, что я очень зауважал инженеров — людей, который умеют и могут проектировать и создавать новые вещи. В голове сразу нахлынули воспоминания об устройствах, который я разбирал в детстве (да и не только). Эти забавные ситуации, когда при откручивании последнего болтика, как чёрт из табакерки, вылетало несколько мелких пружинок и деталек, которые было совершенно невозможно упаковать обратно.

Однажды я решил сделать небольшое устройство (“Security Access Tuner” из игры Alien: Isolation) — контроллер, экран, пара элементов управления, да упаковать это всё в небольшой корпус, который планировалось напечатать на 3d принтере. Тогда я ещё и подумать не мог, сколько же времени потребуется, чтобы все эти мелочи собрались в одно целое…

Доброго времени суток! Среди моих знакомых бытует мнение, что самостоятельно изготавливать печатные платы (ПП) бесполезно. Учитывая, что современные компоненты далеко ушли от DIP корпусов, то кустарно травить платы под них даже и не стоит пытаться. Тем не менее необходимость в быстрой оценке того или иного компонента всегда есть, и ждать несколько суток заказанной платы времени нет. И это учитывая, что заказ за «несколько суток» дорог, для одноразовой задачи.

В данной статье я хочу изложить порядок действий, которые позволят быстро изготавливать ПП под компоненты в корпусах подобных TQFP-100, то есть с ногами 0,2мм и таким же зазором, и при этом сводить брак к минимуму.

Конечно это способ изготовления плат только для прототипов, но он снижает риски ошибиться при создании конечного устройства.

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

Под катом подробности и трафик.

Осваивая рецепты эффективного развития программного проекта, постарался для себя найти причины, делающие полезным использование принципов развития архитектуры SOLID (статья Как не понимать принципы развития архитектуры SOLID).

Анализ этих принципов позволил выделить несколько ключевых закономерностей и базовых элементов, существующих в разработке. Они позволили описать, понять и внедрить SOLID в реальной работе с программным проектом.

Стало интересно выполнить анализ применимости этих понятий для общепринятых парадигм программирования, например для ООП. Хорошо, если результат этой работы будет полезен и Вам.

Привет Хабр. Наверное каждый, кто хоть раз встречал или провожал родственников или друзей на самолет, пользовался бесплатным сервисом Flightradar24. Это весьма удобный способ отслеживания положения самолета в реальном времени.



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

Наверное каждый, кто хоть раз встречал или провожал родственников или друзей на самолет, пользовался бесплатным сервисом Flightradar24. Это весьма удобный способ отслеживания положения самолета в реальном времени.



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

Восполним этот пробел. О том, как это работает продолжим под катом.

Как обычно происходит код-ревью? Вы отправляете пул-реквест, получаете обратную связь, вносите исправления, отправляете фиксы на повторный ревью, затем получаете одобрение, и происходит мерж. Звучит просто, но на деле процесс ревью бывает очень трудоемким.

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «Pseudo Lens Flare» автора John Chapman.



Lens flare (блики на линзах) ― это фотографический артефакт, возникающий при рассеивании и преломлении света в системе линз. Хотя он является артефактом, существует множество поводов использовать lens flare в компьютерной графике:

• он увеличивает воспринимаемую яркость и видимый динамический диапазон изображения.
• lens flare часто встречается на фотографиях, поэтому его отсутствие может бросаться в глаза
• он может играть важную роль в стилистике или драматизме, или может быть частью геймплея в играх (представьте блики, ослепляющие игрока)

Традиционно lens flare в realtime реализовывался с помощью технологий, основанных на спрайтах. Хотя спрайты дают легко контролируемые и очень реалистичные результаты, они должны быть размещены явно и требуют данные окклюзии для корректного отображения. Здесь я опишу простой и относительно дешевый screen space эффект, который создает псевдо lens flare из входного color buffer. Он не основан на физике, поэтому результат немного отличается от фотореалистичного, но его можно использовать в комбинации с (или как замену) традиционными sprite-based эффектами.

Продолжаем разговор про 3Д шутер за выходные. Если что, то напоминаю, что это вторая половина:

• Часть первая: отрисовка стен
• Часть вторая: населяем наш мир + оконный интерфейс

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


К сожалению, большинство студентов выбирает простые игры типа 2Д платформеров. Я пишу эту статью для того, чтобы показать, что создание иллюзии трёхмерного мира ничуть не сложнее клонирования марио броз.

Этот текст предназначен для тех, кто только осваивает программирование. Основная идея в том, чтобы показать этап за этапом, как можно самостоятельно сделать игру à la Wolfenstein 3D. Внимание, я совершенно не собираюсь соревноваться с Кармаком, он гений и его код прекрасен. Я же целюсь совсем в другое место: я использую огромную вычислительную мощность современных компьютеров для того, чтобы студенты могли создавать забавные проекты за несколько дней, не погрязая в дебрях оптимизации. Я специально пишу медленный код, так как он существенно короче и просто понятнее. Кармак пишет 0x5f3759df, я же пишу 1/sqrt(x). Мы преследуем разные цели.

Я убеждён, что хороший программист получается только из того, кто кодит дома в своё удовольствие, а не только просиживает штаны на парах в университете. В нашем университете программистов учат на бесконечной череде всяких библиотечных каталогов и прочей скукоте. Брр. Моя цель — показать примеры проектов, которые интересно программировать. Это замкнутый круг: если интересно делать проект, то человек проводит над ним немало времени, набирается опыта, и видит вокруг ещё больше интересного (оно же стало доступнее!), и снова погружается в новый проект. Это называется проектное обучение, вокруг сплошной профит.

Простыня получилась длинная, поэтому я разбил текст на две части:

• Часть первая: отрисовка стен
• Часть вторая: населяем наш мир + оконный интерфейс

Выполнение кода из моего репозитория выглядит вот так:


Это не законченная игра, но только заготовка для студентов. Пример законченной игры, написанной двумя первокурсниками, смотрите во второй части.

Пришли очередные выходные, надо написать пару десятков строк кода и нарисовать картинку, да лучше не одну. Итак, на прошлых и позапрошлых выходных я показал, как делать трассировку лучей и даже взрывать всякое. Это многих удивляет, но комьпютерная графика — очень простая вещь, пары сотен строк голого C++ вполне хватает на создание интересных картинок.

Тема сегдоняшнего разговора — бинокулярное зрение, причём сегодня даже до ста строк кода не дотянем. Умея рендерить трёхмерные сцены, было бы глупо пройти мимо стерепар, сегодня будем рисовать примерно вот такое:

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

Как всегда, в нашем распоряжении только голый компилятор, никаких сторонних библитек использовать нельзя. Я не хочу заморачиваться с оконными менеджерами, обработкой мыши/клавиатуры и тому подобным. Результатом работы нашей программы будет простая картинка, сохранённая на диск. Я совершенно не гонюсь за скоростью/оптимизацией, моя цель — показать основные принципы.

Итого, как в таких условиях нарисовать вот такую картинку за 180 строчек кода?

От переводчика:

Я продолжаю заброшенную серию переводов туториалов от Twinklebear, в оригинале доступных тут, с разрешения переводчика предыдущих уроков серии InvalidPointer. Первые два урока серии переводов в списке — за его авторством, 5 и 6 перевёл AndrewChe. Перевод отчасти вольный и может содержать незначительные поправки или дополнения от переводчика.