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

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

Графы на рис. 1 представляют собой модель автоматной программы в ВКПа. И уже на уровне модели видны основные отличия. Кратко или, так сказать, в первом приближении они сводятся к следующему. На уровне отдельного процесса (автомата) мы сразу разделяем программу на части. Это операторы, названные предикатами и действиями, и управление программы – собственно модель конечного автомата (КА). А на уровне самой программы в общем случае это сеть из автоматов. В соответствии с данным ранее определением все это вместе и составляет автоматную программу.

#include "mbed.h"
DigitalOut myled(LED1);

int main() {
    while(1) {
        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec
    }
}

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

Выводить в консоль «Привет, мир!» я уже умел.
Теоретическое представление, что нужно делать, так же имелось.
Оставалось дело за малым - реализовать задумку.

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

В программировании микроконтроллеров часто приходится писать драйверы периферийных микросхем. Зачастую это 60% всего кода большинства проектов. В этом тексте я написал несколько общих нюансов разработки драйверов периферийных чипов.

Эти правила "написаны кровь".

Нижеприведенный список является моей небольшой коллекцией примеров кода на языке С, которые не являются корректными с точки зрения языка С++ или имеют какое-то специфичное именно для языка С поведение. (Именно в эту сторону: С код, являющийся некорректным с точки зрения С++.)

Этот материал я уже публиковал на другом ресурсе в менее причесанном виде, Я бы, наверное, поддался прокрастинации и никогда не собрался опубликовать эту коллекцию здесь, но из-за горизонта уже доносится стук копыт неумолимо приближающегося С23, который безжалостно принесет некоторые жемчужины моей коллекции в жертву богам С-С++ совместимости. Поэтому мне и пришлось встать с печи, пока они еще актуальны...

Разумеется, язык С имеет много существенных отличий от языка С++, т.е. не составит никакого труда привести примеры несовместимостей, основанные, скажем, на ключевых словах или других очевидных эксклюзивных свойствах С99. Таких примеров вы не найдете в списке ниже. Мой основной критерий для включения примеров в этот список заключался именно в том, что пример кода должен выглядеть на первый взгляд достаточно "невинно" для С++-наблюдателя, т.е. не содержать бросающихся в глаза С-эксклюзивов, но тем не менее являться специфичным именно для языка С.

Перед тем как приступать к основной части статьи, наверное стоит начать с вопросов «зачем». В контексте данной статьи их три:

 1)      Почему Postgres

2)      Зачем Public Cloud

3)      Почему Yandex.Cloud (в контексте постгреса)

Почему Postgres

              Ну да, казалось бы если речь пошла о cloud инфраструктуре то наверняка о быстром расширении и новом проекте. Postgres появился достаточно давно, может нужно рассмотреть альтернативные решения? Когда я выбираю СУБД для проекта я обычно заглядываю на https://db-engines.com/

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

Реализация собственных библиотек не занимает большого количества времени. Но данные решения будут малофункциональными и могут быть недотестированными. Поэтому разработчики используют готовые решения по управлению и записи логов во время работы программы.

Плюсы использования подобных решений заключается в том, что они являются более универсальными, т.к. должны работать с любым кодом и иметь возможность сохранять записи в различных форматах (от простой записи в консоль до записи результатов в базу данных).

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

В данной статье представлен обзор трех наиболее популярных библиотек логирования: Log4Net, SeriLog, NLog.

Всем привет! Меня зовут Леонид, я владелец сервиса Поиск VPS. Весной я уже опубликовал две статьи по оплате услуг иностранных хостеров при помощи SWIFT и криптовалют. К сожалению, карты, выпущенные российскими банками, все еще не работают в большинстве стран мира, да и не у всех есть желание и возможность оплачивать услуги указанными выше способами, поэтому сегодня я хочу предложить выборку хостеров, принимающих оплату российскими картами и предоставляющих виртуальные серверы не в России.

При составлении списка я ориентировался на количество стран, в которых возможно заказать наиболее универсальную услугу, а именно виртуальные серверы, а также минимальную цену не выше 300 рублей, 5 долларов или 5 евро в месяц. У большинства хостеров возможен заказ услуг в России, а там, где это возможно, приведена ссылка на точки Looking Glass.

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

Традиционно мир разработки для встраиваемых решений делится на программирование ПЛК, где используются среды стандарта IEC 61131 и разработку на С/С++ для микроконтроллеров и embedded Linux. Стандарт IEC 61499 является наследником стандарта IEC 61131 и предназначенн для разработки распределенных систем управления. Основным строительным элементов IEC 61499 является функциональный блок похожий на конструкцию языка FBD. Опенсорсные инструменты Eclipse 4diac IDE и Eclipse 4diac forte позволяют разработать распределенную систему управления из нескольких Raspberry PI или компьютеров с Linux, Windows или Freertos. Доступна работа с распространенными полевым шинами и возможность расширения библиотек блоков на С++.

Уже давно вышла версия Qt4 c поддержкой QML. С тех пор многое допиливалось и сейчас технология является довольно успешной и стабильной. Однако нормального описания так и не удавалось найти на русском языке. А на английском написано так, как говорится, "правой рукой, да левое ухо". Поэтому решил начать перевод самоучителя (пока базового, затем планирую расширенный) на русский язык. Собственно, найти самоучитель можно на моем GitHub или здесь ниже.

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

Цель этой статьи показать и объяснить многообразие дистрибутивов Линукс. Показать основные сходства (они же все почему то называются "Линуксы" или даже правильнее "GNU/Linux") и основные различия (если бы не было различий их бы столько не существовало).

Плюс рассмотрим несколько наиболее задаваемых новичками вопросов:
- Сколько их (Linux-дистрибутивов)? Зачем так много?
- Основанный на другом дистрибутиве" - не пиратство ли это?
- Платный Linux - Как можно продавать то, что по определению распространяется бесплатно?
- Что такое "отечественный Linux"?

Те, кто внимательно и не очень следят за новостями в сфере ИТ последние лет пять, должны были заметить некоторые импортозамещающие настроения в стране. Это настроение вдохнуло жизнь и в рынок отечественной разработки ОС. Я решил разобраться, что сегодня представляет собой отечественный рынок ОС, и у каких, на мой взгляд, проектов есть будущее.