Продолжение истории про Mothers of All Demos — оператором видеокамеры на этом мероприятии был некий Стюарт Бранд — издатель журнала The Whole Earth Catalog, биолог, эколог и активист.

Стюарт был далек от компьютеров, но зато, например, убедил NASA сделать и опубликовать один из первых снимков Земли из космоса — чтобы показать людям, насколько она маленькая и хрупкая. Он же придумал ежегодно отмечаемый "День Земли"

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

А знаем мы его по одной очень известной фразе, популяризированной Стивом Джобсом:

Оставайтесь голодными, оставайтесь безрассудными!

Эта фраза была напечатана на последней странице The Whole Earth Catalog выпуска 1974 года, и именно её процитировал Джобс в речи перед выпускниками Стэнфорда, упомянув, что зачитывался этим журналом, и вообще это было "что-то типа Гугла на бумажном носителе, и задолго до Гугла".

Вот так всё связано хитрыми способами!

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

Так ISO 15926 начался в нефтегазовой индустрии, а сейчас считается общим стандартом для семантического представления 4D-модели (с учетом времени) любой сложной инженерной конструкции и её жизненного цикла в любой отрасли. Медицинский стандарт HL7 содержит самую подробную структуру для хранения личных имен, что мне только встречалась (из 11 полей и 13 типов).

А в образовании есть модель интеграции технологий в обучение (считай — уровень или глубина цифровизации) SAMR:

S — Substitution, простая замена старой технологии на цифровой эквивалент без изменения функции.
A — Augmentation, расширение — технология выполняет ту же функцию, но с небольшим расширением.
M — Modification, изменение — технология значимо меняет способ выполнения функции.
R — Redefinition, переопределение — применение технологии позволяет выполнить совсем другую задачу, ранее непредставимую.

На примере такси:

S — раньше такси вызывали по телефону в конкретной компании-перевозчике, теперь можно вызвать через мессенджер/чат-бот/форму на сайте (таксисту вызов передает оператор по рации);

A — На сайте можно посмотреть историю своих заказов и текущий заказ;

M — Можно вызвать такси в мобильном приложении перевозчика, адрес определяется автоматически, у таксиста тоже есть приложение, где он видит вызов, оператор не нужен;

R — Каждый может стать таксистом, если есть своя машина и немного свободного времени. Не нужно знать контакты конкретного перевозчика — пользователь вообще не думает, кто и из какой конкретно компании приедет. У всех пассажиров и всех таксистов приложение одного координатора. Кто бы мог такое придумать!

У нас уровень трансформации обычно измеряют другими ступенями: компьютеризация, информатизация, цифровая трансформация (поставили компьютеры и начали на них решать какие-то задачи; создали интегрированную систему для поддержки бизнес-процессов; перестроили бизнес-процессы, и каждый новый сразу проектируем в цифре). Иногда говорят про перестройку бизнес-модели на последнем шаге. это уже ближе к SAMR. В другом подходе последний уровень почему-то "мышление на основе данных", что бы это ни значило. Redefinition мне больше нравится!

Вы тоже, когда автоматизируете процессы, задумайтесь — чем вы занимаетесь? Заменой, расширением, изменением или переопределением?

Аналитик, особенно бизнес-аналитик, по моему убеждению занимается именно цифровизацией предприятия — может быть, не всего, а отдельных процессов, но в пределе — может и всего, как CDTO (директор по цифровой трансформации). Это к вопросу о возможном карьерном треке и кем может быть опытный аналитик, если не архитектором и не менеджером проектов.

Мы всё неправильно понимаем про HTTP метод PATCH.

Иногда читать стандарты очень увлекательно — становится понятно, что люди имели в виду на самом деле. Читать книги и статьи опаснее — там уже личные интерпретации, кто как понял. Почти во всех примерах, что мне встречались, тело запроса PATCH описано, как набор новых значений полей в JSON — с оговоркой, что в случае PUT мы должны были бы передать все поля, а не только изменившиеся, а в случае PATCH — только изменившиеся.

Но в стандарте — RFC 5789 — написано совсем другое! В запросе PATCH должен передаваться набор изменений, применяемых к ресурсу, в формате "патч-документа". Что это за формат — зависит от медиа-типа ресурса. В реестре медиа-типов IANA есть, например, типы патч-документов для json: application/json-patch+json и application/merge-patch+json; и тип для XML: xml-patch+xml (ну ещё несколько специфических).

Документ JSON-patch [RFC 6902] выглядит именно как набор операций, вносящих изменения в JSON:

   [
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]

op — это, понятно, название операции, вот какие операции могут быть:

add — добавить элемент в массив или свойство в объект;
remove — удалить свойство объекта или элемент массива;
replace — соответственно, заменить (как последовательное применения remove и add);
move — переместить значение из одного места (пути) в другой (тоже как remove и add, но у add будет другой путь);
copy — скопировать значение и вставить в другое место;
test — проверить значение по указанному адресу на соответствие (без масок или регулярных выражений, просто на совпадение).

Понятно, что неидемпотентным PATCH делает именно операция add — если будем применять её несколько раз к массиву, добавится много элементов вместо одного.

То, как обычно описывают формат применения PATCH — больше похоже на merge-patch+json: там мы действительно передаем только изменившиеся свойства, и null для тех свойств, которые хотим удалить.

В любом случае, тип медиа не должен быть просто application/json — по стандарту (а точнее — по errata к стандарту, списку исправлений), сервер вообще должен возвращать ошибку 415, если в запросе PATCH приходит тот же медиа тип, что у ресурса — то есть, не json-patch, просто json. Это чтобы избежать неоднозначности интерпретации. А в каких форматах сервер готов принимать патч-документ — он должен сам сказать в ответе на запрос OPTIONS: Accept-Patch: application/prs.example.patch+json, application/json-patch+json, application/merge-patch+json.

Вот так PATCH должен работать на самом деле. Ясно, что он так практически никогда не работает, так что можете этими знаниями блеснуть на собеседовании, разве что. И то — будьте осторожны, а то интервьюер примет вас за зануду-теоретика, выучившего стандарты, но далекого от практики. А на практике ни один фронтендер не будет вам конструировать сложный патч-документ, когда можно передать просто набор изменившихся полей. Ну, или пока дело не дойдет до какого-то очень сложного по структуре, со многими уровнями вложенности объекта.

По сети, говорят, ходит флешмоб про 20 книг, которые до сих пор с вами или сильно повлияли на вас: без объяснения, только обложки.

Вот мои 20 (это те, что "по специальности"). Удивительно тут, конечно, что по системному анализу и управлению требованиями книг тут не так много — даже не понятно, откуда я этого всего нахватался.