В процессе разработки, например, для Intel Edison или Galileo, может случиться так, что нужного для экспериментов устройства под рукой не оказалось. Похожее происходит и тогда, когда «железо» есть, но установленная на нём ОС не поддерживает всех необходимых для проекта возможностей. Что делать?

Один из вариантов решения этой проблемы – запуск целевой операционной системы на виртуальной машине. На ней можно компилировать, развёртывать и тестировать программы. Сегодня поговорим о том, как создавать образы Yocto Linux, подходящие для запуска в виртуальных средах, например, в простом программном эмуляторе QEMU. Кроме того, подобные образы можно использовать в системах с гипервизорами, скажем, в Microsoft Hyper-V на Windows.

После выхода Ubuntu 16.04 (новый LTS релиз), systemd стал реальностью всех основных дистрибутивов Linux, использующихся на серверах. Это означает, что можно закладываться на расширенные возможности systemd, не рискуя оставить часть пользователей приложения «за бортом».

Этот пост о том, как реализовать многоворкерное приложение средствами systemd.

Abstract: Использование шаблонов сервисов и target'ов для запуска нескольких инстансов сервиса (реализация «воркеров»). Зависимость PartOf. Немного про [install] секцию у unit'ов.

Вступление

Многие языки программирования с плохой или никакой многопоточностью (Python, Ruby, PHP, довольно часто C/C++) используют концепцию «воркера». Вместо того, чтобы городить сложные отношения между тредами внутри приложения, они запускают несколько однопоточных копий приложения, каждое из которых берёт на себя кусок нагрузки. Благодаря опции SO_REUSEPORT есть даже возможность «вместе» слушать на одном и том же порту, что покрывает большинство задач, в которых возникает потребность в воркерах (собственно, обычные серверные приложения, реализующие API или обслуживающие веб-сайт).

Но такой подход требует наличия «супервизора», который отвечает за запуск копий, следит за их состоянием, обрабатывает ошибки, завершает при всякого рода stop/reload и т.д. При кажущейся тривиальности — это совершенно не тривиальная задача, полная нюансов (например, если один из воркеров попал в TASK_UNINTERRUPTIBLE или получил SIGSTOP, то могут возникнуть проблемы при restart у не очень хорошо написанного родителя).

Есть вариант запуска без супервизора, но в этом случае задача reload/restart перекладывается на администратора. При модели «один процесс на ядро» перезапуск сервиса на 24-ядерном сервере становится кандидатом в автоматизацию, которая в свою очередь требует обработки всех тех же самых SIGSTOP и прочих сложных нюансов.

Одним из вариантов решения проблемы является использование шаблонов сервисов systemd вместе с зависимостью от общего target'а.

Выложить проект с открытым программным кодом – это больше, чем выложить код в Интернете.

Интерес к программным продуктам с открытым исходным кодом растёт последние 10 лет. Linux стоит и в стиральных машинах, и в боевых дронах. Большинство программистов не могут представить свою жизнь без широкого ассортимента бесплатных и открытых инструментов в своем распоряжении.

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

Чем вы можете помочь своему проекту, чтобы его заметили?

Маргарет Гамильтон стоит рядом с написанным ей исходным кодом бортового компьютера «Аполлона»

Лаборатория реактивного движения (Jet Propulsion Laboratory) — научно-исследовательский центр НАСА, ответственный за большинство беспилотных космических кораблей США. Там пишут много кода, и права на ошибку у них намного меньше, чем у обычных программистов.

В JPL пишут на Си, и на их сайте есть документ "JPL Institutional Coding Standard", описывающий жесткие стандарты кодирования внутри организации. Они напоминают правила программирования для встроенных (embedded) систем и систем реального времени, с ограниченными ресурсами. Но многие из правил эти просто принципы хорошего программирования. Ограничение сложности, максимальное упрощение для последующего чтения кода и отладки, отсутствие побочных эффектов. Мы в Хекслете постоянно говорим об этом в вебинарах и, конечно, в самих курсах. Мы считаем очень важным как можно раньше поднимать эти темы, поэтому про функции и побочные эффекты начинаем говорить в самом первом курсе «Основы программирования», который рассчитан на новичков. Это бесплатный курс, кстати, и в нем есть практика на языке JavaScript.

Спасибо хабраюзеру Boletus за важную поправку и дополнение:
В 2006 году Gerard Holzmann с коллективом сформулировал 10 основных правил для JPL в документе «The Power of 10: Rules for Developing Safety-Critical Code». Они вошли в основу нынешнего стандарта, наряду с MISRA C и другими дополнениями. Статья в Википедии.

Вот перевод этого списка.

Привет, хабравчане!

Меня зовут Михаил Матросов, я технический менеджер в компании Align Technology. Сегодня я поработаю капитаном и немного расскажу об основах современного С++.

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

Мне бы хотелось поговорить об этих основах и начну я со своей любимой темы. Будем говорить об операторах new и delete. А точнее, об их отсутствии. Я расскажу, как писать надёжный и современный код на С++ без использования операторов new и delete.

Казалось бы, тема стара как мир, Саттер и Майерс в своё время всё разложили по полочкам. Именно поэтому я не буду вдаваться в ненужные подробности, отправляя читателей к первоисточникам. Моя цель собрать информацию по вопросу в одном месте, дать соответствующие ссылки и сформулировать ёмкие рекомендации.

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


Изображение взято с сайта behappy.me

Язык С++ по сей день является одним из самых востребованных и гибких языков программирования. Но иногда возможностей языка не хватает, несмотря на то что стандарт развивается и расширяется. С такой проблемой столкнулся и я в процессе разработки 2D движка для игр. Я стоял перед необходимостью решения несколько нетривиальных задач, таких как сериализация, анимирование и связка с редактором. Для этого отлично подходит рефлексия. Готовые решения из сети, к сожалению, мне не подошли, поэтому пришлось конструировать свой велосипед.

Далее описаны детали реализации и демо проект. Кому интересно — добро пожаловать под кат.

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

enum State {Idle, Fidget, Walk, Scan, Attack};
enum Direction {North, South, East, West};

Гораздо удобнее, когда во время отладки в консоль выводится сообщение типа “State: Fidget” вместо “State: 1”. Также частенько бывает нужно сериализировать перечисления в JSON, YAML или иной формат, причём в виде строковых значений. Помимо того, что строковые воспринимать легче, чем числа, их применение в формате сериализации повышает устойчивость к изменениям численных значений констант перечислений. В идеале, "Fidget" должен ссылаться на Fidget, даже если объявлена новая константа, а Fidget имеет значение, отличное от 1.

К сожалению, в С++ нет возможности легко конвертировать значения перечислений в строковые и обратно. Поэтому разработчики вынуждены прибегать к разным ухищрениям, которые требуют определённой поддержки: жёстко закодированным преобразованиям или к использованию неприглядного ограничительного синтаксиса, наподобие Х-макросов. Кто-то дополнительно использует средства сборки для автоматического преобразования. Естественно, это только усложняет процесс разработки. Ведь перечисления имеют свой собственный синтаксис и хранятся в собственных входных файлах, что не облегчает работу средств сборки в Makefile или файлах проекта.

Однако средствами С++ можно гораздо проще решить задачу преобразования перечислений в строковые.

От переводчика: У меня возникла необходимость разобраться с работой UDP-сокетов в неблокирующем режиме в java и создать свой собственный класс для работы с сетевыми соединениями на их основе. К сожалению, толковой русскоязычной документации на эту тему я не нашёл. Зато наткнулся на несколько попыток на хабре осветить тему создания надёжного соединения поверх UDP. В том числе и перевод нескольких статей Гленна Фидлера, сделанный пользователем bvasilyev. И хотя статьи рассматривают создание подобного подключения для применения его в играх (не совсем то, что мне необходимо), а также языком реализации является не java, а c++, они стали для меня отправной точкой. К сожалению bvasilyev около года назад прервал перевод данного цикла, а самое интересное осталось на языке оригинала. Поэтому я решил перевести четвёртую статью цикла и переписать реализацию виртуального соединения из третей статьи цикла на java (чуть позже выложу). Ну а для того, чтоб данной статьёй мог воспользоваться кто-либо, кроме меня, выкладываю её здесь. Профессиональным переводом, к сожалению, никогда не занимался, всегда изучал англоязычную документацию. Но в данном случае, из-за многочисленного употребления некоторых слов в совершенно различных значениях, а также в роли наименования всевозможных определений, неоднократно — в пределах одного предложения, счёл более целесообразным осуществить перевод, а после уже работать с текстом на привычном для себя языке. Поправки и аргументированные предложения приветствуются.

Первая статья
Вторая статья
Третья статья

(напомню: переведены bvasilyev)

---

Надежность, упорядочивание и избежание перегрузок поверх UDP

Вступление

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей четвёртой статье из цикла “Сетевое программирование для разработчиков игр”.

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

Теперь мы будем добавлять надёжность, упорядоченность и предотвращение перегрузок к нашему виртуальному UDP соединению.

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

Проблемы с TCP

Те из вас, кто знаком с TCP, знают, что он уже имеет свою внутреннюю концепцию соединений, с надёжной и упорядоченной системой передачи пакетов и предотвращением перегрузок, так зачем же мы пишем свою собственную мини версию TCP на основе UDP?

Я хотел бы рассказать о том, как я писал реализацию «Hello, World!» на C. Для подогрева сразу покажу код. Кого интересует как до этого доходил я, добро пожаловать под кат.

#include <stdio.h>
const void *ptrprintf = printf;
#pragma section(".exre", execute, read)
__declspec(allocate(".exre")) int main[] =
{
    0x646C6890, 0x20680021, 0x68726F57,
    0x2C6F6C6C, 0x48000068, 0x24448D65,
    0x15FF5002, &ptrprintf, 0xC314C483
};

Некоторое время работаю с Education версией LEGO Mindstorms EV3. Однажды подумалось: «Плохо, что нельзя писать под EV3 программы на Python, всё таки создавать в визуальной среде программирования более-менее серьёзные программы достаточно сложно и долго. Хотя...».

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

Как введение могу сказать что более 4 лет назад на самом рассвете моей карьеры в IT я собеседовался в одну всем известную и очень большую иностранную фирму. Как полагается в таком случае собеседование было на английском языке.

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

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

В статье подробно рассказано о самомодифицирующимся коде (СМК), и о том, как его использовать в своих программах. Примеры написаны на C++ с использованием встроенного ассемблера. Ещё я расскажу о том, как выполнять код на стеке, что является существенным козырем при написании и выполнении СМК.

1. Вступление

Ну что ж, поехали. Статья обещает быть длинной, так как мне хочется написать её такой, чтобы у вас не возникло никаких вопросов. На тему СМК уже существует миллион статей, но здесь представлено моё видение проблемы – после сотен часов написания СМК… Я попытаюсь впихнуть все свои труды сюда. Всё, хватайте томатный сок (или что вы там предпочитаете пить), делайте музыку громче и готовьтесь узнать, как избавить своё приложение от начинающих кракеров! Попутно, я расскажу вам о памяти Windows и некоторых других вещах, о которых вы даже и не подозреваете.

После прочтения статьи Самая опасная функция в мире С/С++ я счёл полезным углубиться во зло, таящееся в тёмном погребе memset, и написать дополнение, чтобы шире раскрыть суть проблемы.

Lego Serious Play или, сокращённо, LSP — это необычный и пока еще не очень распространённый метод игрового моделирования (или – фасилитации). Не запутано начали? Тогда продолжим и, обещаем – ничего сложного в этом нет.

Разберёмся для начала с тем, что такое «фасилитация».
Говоря простым и понятным языком, «фасилитация» – это организация и проведение эффективных встреч, где критерием эффективности является достижение поставленной цели встречи в определённые для этой встречи сроки. Например, если мы организуем двухчасовое планирование итерации, фасилитатор следит, чтобы команда не отвлекалась на смежные темы и не уходила слишком глубоко в детализацию, чтобы через 2 часа у нас появился готовый и качественный план. Причём качество плана подразумевает вовлечённость в процесс всех участников встречи

Теперь вернёмся к тому, с чего начали – Lego Serious Play.

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

Все знают Францию в основном по известным достопримечательностям таким как: Эйфелева башня, Лувр, Триумфальная арка, Версаль и т.д. Но мало кто знает о Парижском музее ремесла и искусств, который открывает для своих посетителей много новых и захватывающих экспонатов.
Музей искусств и ремёсел, находящийся во французской столице, имеет полное право на то, чтобы называться старейшим техническим музеем в мире. Представленные в нём экспонаты рассказывают посетителям о том, как развивалась европейская наука и техника с 16-го по 20-й век, охватывая практически все области, в которых были сделаны открытия и изобретения — от ткацкого ремесла до фотографии.

Давным-давно я имел радость играть в замечательнейшую RTS под названием «Периметр: Геометрия Воины» от отечественного разработчика K-D Labs. Это игра о том, как огромные летающие города под названием «Фреймы» бороздят просторы «Спанджа» — цепи соединенных между собой миров. Сюжет достаточно странный и абстрактный, но гораздо более интересной и инновационной составляющей игры была одна из ее технических особенностей, а не сюжет. В отличие от большинства RTS, где сражения происходят на статической местности, в «Периметре», одной из ключевых игровых механик был терраформинг. У игрока были средства манипулировать ландшафтом с целью возведения на нем своих сооружений а также целый арсенал боевых единиц, способных этот ландшафт превратить в потрескавшийся, поплывший и изрыгающий раскаленные камни/противных насекомых ужас.

Как известно, мир RTS нынче переживает некоторый упадок. Инди-разработчики слишком заняты тем, что клепают ретро-платформеры и rouge-like игры зубодробительной сложности, и поэтому, переиграв в «Периметр» некоторое время назад я решил, что должен и сам попробовать реализовать что-то подобное — идея была интересной и с технической и с геймплейной точек зрения. Обладая некоторым практическим опытом в разработке игр (ранее я совершал попытки сделать кое-что на XNA), я подумал, что чтобы добиться хоть какого-то успеха в одиночку мне придется воспользоваться чем нибудь более высокоуровневым и простым. Выбор мой пал на Unity 3D, чья пятая версия только-только вышла из под пресса.

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

All specialists unanimously agreed that a reading [of the Enigma] is impossible.
Admiral Kurt Fricke, Chief of Naval War Command

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

Не так давно я участвовал в проекте написания прошивки для некоторого устройства. В процессе работы возник вопрос, а как, собственно, взаимодействовать с «большим братом» (управляющим компьютером)? Поскольку в качестве «большого брата» закладывались совершенно разные устройства (различные смартфоны, планшеты, ноутбуки с различными ОС и прочее), планировалось использовать web-приложение, что диктовало использование JSON для обмена сообщениями.

В итоге получилась легкая и быстрая библиотека сериализации/десериализации JSON. Основные фичи данной библиотеки:

• в базовом функционале (без использования контейнеров STL) не использует динамическую память, вообще;
  
• состоит только из заголовочных файлов (headers-only);
  
• есть поддержка контейнеров STL;
  
• позволяет создавать расширения для обработки произвольных типов.
  

Конференции бывают разные. Некоторые собирают огромные толпы зрителей, другие могут быть интересны лишь полутора специалистам.

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

На самом деле, пост не о том.

Так уж вышло, что мне довелось выступать на означенной конференции, где я на пальцах и с приплясываниями рассказывал, что такое LLVM, чем интересна нотация SSA, что такое IR код и, наконец, как так получается, что детерменированные на первый взгляд C++ программы, оказывается, провоцируют неопределенное поведение.

Кстати, этот доклад можно поставить пятым номером в серии статей про виртуальную машину Smalltalk. Многие просили подробнее рассказать о LLVM. В общем, убиваем всех зайцев сразу. Заинтересовавшимся, предлагаю «откинуться на спинку кресла», опционально налить чего-нибудь интересного и послушать. Обещаю, что больше часа времени я не отниму.

Ах да, под катом можно найти пояснения тех моментов, которым не было уделено должное внимание на конференции. Я постарался ответить на часто задаваемые вопросы и детально разобрать листинги LLVM IR. В принципе, текстовую часть статьи можно читать как самостоятельное произведение, тем не мене я рассчитывал на то, что читатель обратится к нему уже после просмотра видео.

Введение в Интернет Вещей



Вы просыпаетесь утром, а браслет для сна на вашем запястье уже успел записать, как вы спали, и загрузил данные в Twitter. Кофемашина получила данные из Twitter о том, что вы проснулись, и начала варить для вас утреннюю чашку крепкого напитка.

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

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