illumium.org

На сегодняшний день существует целый ряд методологий программирования сложных систем реального времени. Одна из таких методологий носит название ФРП (FRP). Она впитала в себя шаблон проектирования, называемый Наблюдатель (Observer) с одной стороны, а с другой, как не трудно догадаться, принципы функционального программирования.

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

Тема разработки аппаратных мониторов довольно актуальна и вместе с тем мало освещена в интернете. Программная система управления, работающая в реальном времени параллельно с управляемым объектом, априори является критической системой. Это означает, что к ней предъявляются особые требования в части надёжности: такие системы не должны демонстрировать неадекватное поведение никогда. Давно установлен эмпирический закон: с нарастанием сложности, надёжность любой системы падает.

Это продолжение цикла статей об операционной системе с чисто функциональной сборкой и конфигурацией NixOS. Мы уже научились устанавливать и настраивать её тут. Настало время сделать нечто бо́льшее, нечто действительно продвинутое, то ради чего, собственно, и стоит использовать именно такую ОС. Настало время написать свои собственные модули конфигурации.

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

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

Давно валялись у меня эти модули. Так бы и лежали без дела, если бы нужда в беспроводной связи между удалёнными устройствами в край не припёрла. Устройство весьма продвинутое для своего класса и в то же время относительно дешевое. Выпускается довольно давно, делают все, кому не лень, у меня были Si4432 от SiLabs, а вообще RF22M от HopeRF и IA4432 от ISM тоже самое (почти).

Однажды мы уже решали проблему модернизации WEB-а. Тогда мне не удалось реализовать самую правильную идею: создать некий API для генерации содержимого, реализации которого будут созданы как для клиента, так и для сервера. Но времена изменились, и ныне проблема не актуальна.

Почти всегда клиентское приложение хочет получить с сервера некий набор однотипных данных. И чтобы сформировать этот набор, серверу, в свою очередь, требуется выполнить запрос к хранилищу этих данных. На каждом этапе происходит какая-то промежуточная обработка, пока не получится то, что может быть отдано клиенту как результат. В REST API обычно используется компактное представление данных в формате JSON.

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

Нет, конечно, возможность объявлять хитрые специфические операторы — одна из полезнейших возможностей Haskell, и нет ничего плохого в том, чтобы так поступать. Плохо другое, объявив операторы &&@ и ||@, мы по сути продублировали функциональность. Булеву алгебру не мы изобрели, стандартные операторы && и || давно существуют и делают понятные вещи. Так зачем же снова изобретать велосипед, когда правильнее было бы адаптировать то, что уже есть.