Проблема взаимопонимания

Представьте себе ситуацию: вы — фрилансер и работаете с Ext. С вами удалённо работает один (или несколько) разработчиков back-end. Работа идёт быстро и гладко. Но вот вот случилось так, что разработчик серверной части сменился. Если у нового коллеги есть опыт взаимодействия с Ext — всё замечательно. Но вот если человек впервые будет писать back-end для Ext или впервые будет писать для веба (такое тоже случается), то вам будет необходимо найти общий язык.
И вот тут могут начаться проблемы…
Придётся тратить время на простое объяснение протокола, объяснения как должен реагировать сервер на те или иные запросы. Чтобы избежать этого, я подготовил документ, описывающий все (ну или почти все нюансы стандартного для Ext протокола). Этот документ и представлен под катом.

Данный топик просвещен проблеме обмена данными в системах промышленной автоматизации м\у ПЛК и различным программном обеспечении. Прежде чем приступить непосредственному к изложению, хочу сказать, что нахожусь в дурацком положении… Дело в том, что основная часть моих коллег по цеху не являются ИТ-специалистами и работаю в рамках тех инструментальных средств, которые являются стандартом «де-факто» — SCADA пакеты, среды разработки для ПЛК и OPC сервера. Мало кого из них интересует, что находится под «капотом» этих инструментов, хотя большинство проблем, об которые они спотыкаются, кроются именно там и заложены в базовых технологиях. С другой стороны АСУ ТП довольно специфичная область и я не уверен, что программист без опыта работы в данной сфере сможет проникнутся тем, что я попытаюсь донести в этом посте. Вот и получается, что данный топик предназначен для небольшого процента специалистов, которые разбираются в ИТ и АСУ ТП одновременно.

Эта статья является второй из серии статей о нововведениях на сайте Государственной Думы (статья 1).

В настоящий момент набирает популярность концепция open government («открытое государство»). К примеру, на сайте data.gov публикуются большие объемы данных государственных ведомств США, а на сайте data.gov.uk публикуются аналогичные материалы Великобритании. Важным аспектом публикации структурированной информации является возможность её получения в машиночитаемом виде. Понятно, что и HTML таблицу можно достаточно успешно распарсить, но предоставление информации в удобном для интеграции с внешними системами виде — очень важный показатель открытости. Поэтому, разработка API для системы поиска по законопроектам стала важным этапом реализации концепции «открытое государство» в рамках сайта Государственной Думы. Теперь данные о законопроектах могут быть легко интегрированы во внешние информационные системы. Например, аналитический портал может рядом со статьей, посвященной тому или иному законопроекту, разместить виджет, который будет отражать актульную информацию о ходе рассмотрения законопроекта.

Разработчики часто просят рассказать о моём опыте использования Backbone.
Многие слышали об этом MVC-фреймворке, смотрели примеры и документацию, но не решаются начать с ним работать. Поэтому вчера я сделал мини-доклад на встрече MoscowJS, призванный рассказать о том, как мы построили базовую архитектуру и какие получили плюсы. И сегодня в этой статье я публикую слайды, схемы и краткое описание.

trivia: REST и виртуальные машины не совместимы.

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

Итак,
тезис 1: REST хорошо, *-RPC (например, XML-RPC, JSON-RPC) — плохо.
тезис 2: Т.к. REST хорошо, его нужно использовать для управления виртуальными машинами (в частности, в облаке).

На первый взгляд так и есть. Например, если мы хотим поменять атрибут (допустим, атрибут «загрузочный диск») для виртуальной машины, то мы пишем:

PUT .../vm333/disk1/bootable
enable=true
PUT .../vm333/disk1/bootable
enable=false

Или даже так:

POST /vm/333/disk1/bootable
DELETE /vm333/disk1/bootable

Если мы хотим создать диск, мы говорим POST /vm333/disk2 и передаём атрибуты (вроде размера или хранилища).

Однако, это хорошо только до того момента, пока наша инфраструктура напоминает записи в БД.

А теперь простой вопрос: как в REST будет выглядеть команда перезагрузки виртуальной машины? Ведь состояние машины не меняется, как была running, так и остаётся. Очевидно, что перезагрузка не идемпотентный вызов, то есть мы должны говорить POST. Но 'POST что и куда?'. Заметим, даже shutdown/start вполне себе укладываются в POST power-state'а. Но вот ребут — который нарушает логику «имманентности» состояния объекта в БД и приводит нас в жестокий императивный мир — увы, не укладываются. Аналогичные проблемы будут при операции 'install' (запуск установки OS).
Причина тут куда более глубокая, чем просто «не очень хорошо получается». Извините за слово «онтология», но эта причина — онтологическая.

Суть проблемы