В этот день 56 лет назад, 9 декабря 1968, прошло событие, которое потом назвали "Мать всех презентаций" — 'Mother of All Demos'. Дуглас Энгельбарт продемонстрировал возможности своей системы NLS, oN-Line System.

Впервые в одной системе были показаны следующие идеи:
- растровый графический монитор
- графический интерфейс
- окна в интерфейсе
- мышь
- гипертекст, ссылки
- динамическое связывание (когда программа "на лету", без перекомпиляции определяет, какую библиотеку загрузить для обработки файла)
- текстовый редактор
- совместное редактирование документов
- электронные письма с ссылками и документами
- видеоконференции с шэрингом экрана
- управление версиями
- вывод экрана на проектор

Ещё раз: 56 лет назад, 1968 год. Компании ещё не все перешли на электронные терминалы, многие до сих пор для ввода и вывода используют перфоленты, люди считают на логарифмических линейках.

Презентация просто взрывала мозг! Да, это была экспериментальная система, но она оказала влияние на всё дальнейшее развитие технологий, появление и возможности персонального компьютера. Часть команды Энгельбарта потом перешла в Xerox, которая в 1973 выпустила персональный компьютер Xerox Alto — с мышью и оконным интерфейсом. Он вдохновил Стива Джобса на создание Macintosh, ну и так далее.

Алан Кей, тогда ещё студент магистратуры, был на презентации, проникся, потом в Xerox PARC придумал объектно-ориентированное программирование и язык Smalltalk.

Дэна Бриклина это демо вдохновило на создание VisiCalc — первого табличного процессора, дедушки Excel.
На презентации были и другие люди, о многих из которых теперь написано в Википедии.

Но главная идея, из которой все эти инструменты у Энгельбарта родились — расширение ментальных возможностей человека, ни много ни мало. Она опирается на статью ещё 40-х годов "Как мы можем мыслить" Вэнивара Буша.

В этом смысле интересно посмотреть на свои системы — исходим ли мы из того, что помогаем человеку мыслить?

Я смотрю, вам понравился пост про философию :) Тогда держите ещё один. Стэнфорд поддерживает ресурс "Стэнфордская философская энциклопедия", в частности, там есть раздел "Философия компьютерных наук".

В нем, например, предпринимается попытка разъяснить, что такое computer science — наука или инженерия?

Интересно, что тут опять возникает рационалистский оптимизм: сначала (с 1940-х до 1970-х) computer science рассматривалась, как подраздел математики: программа написана на формальном языке, значит, каждый оператор и их последовательность можно рассматривать как математическое выражение, в, конечном итоге, формально доказать правильность работы программы. Этим активно занимались Дейкстра и Хоар; и Дейкстра так протестовал против оператора GOTO в том числе потому, что тот мешал формальной верификации. Кроме того, Дональд Кнут поддерживал рассуждение, что компьютерная система — это творение человеческих рук, а значит её поведение может быть в точности предсказано.

В 1970-е, однако, системы стали действительно большими и получили развитые пользовательские интерфейсы, так что и свести все варианты входов системы к некоторому ограниченному множеству, и формально проанализировать все программы со всеми библиотеками стало нереальной задачей. Хотя теоретически это осуществимо (хотя бы и с некоторыми ограничениями), на практике сложность такой верификации на порядки превышала бы сложность создания системы. Поэтому методы computer science стали развиваться в сторону тестирования и оценки надежности или скорее достоверности (reliability), в чем-то походя на методы проверки качества физических изделий.

Хоть мы и не можем проверить работоспособность программы (а тем более комплекса программ) на всём объеме возможных входных данных и внутренних состояний, мы можем проверить некую выборку таких данных и состояний, наиболее статистически вероятных, и считать, что с некоторой вероятностью проверенная программа работает. В каком-то смысле, computer science — это инженерия математики — проверка математических выражений инженерными методами.

Наконец, computer science может рассматриваться как отрасль эмпирической науки — изучающей реально существующие вычислительные системы. Ну и что, что они созданы человеком и не найдено пока природных вычислительных систем — это такой специальный предмет исследования, который всегда создается человеком, но далеко не всегда человеком познаваем. Наверное, можно даже рискнуть назвать это эмпирической математикой — и рассматривать каждую новую систему, алгоритм или язык как своего рода эксперимент.

Ну, будем честными — почти всегда это эксперимент и есть — то ли система будет решать задачи, для которых она предназначена, то ли мы узнаем что-то новое о задачах, желаниях пользователя, вычислительных возможностях и о себе :)

А в следующий раз я расскажу о философских основаниях требований — там тоже интересно, не переключайтесь!

Вам хотелось когда-нибудь озвучить ТЗ? Причем чтобы не просто диктор его зачитывал, а это звучало как-то более интересно? Теперь при помощи AI можно превратить документ в подкаст.

Я взял для примера техническое задание, которое мы показываем на курсе "Системный анализ и разработка требований в ИТ-проектах" в школе Systems.Education, и вот что получилось. (Разговор идёт на английском, так что можете включить субтитры или переозвучить на русском в Яндекс.Браузере — правда, Яндекс немного потерял интонации и кое-где неправильно перевел фактуру)

— Хорошо, так, посмотрим, что тут у нас, эм, вы дали нам эту спецификацию требований к программному обеспечению еще аж 2010 года
— О, вау!
— Да, это система для управления регистрацией лекарственных средств в России. Интересно. Я знаю, о чем ты думаешь.
— Звучит захватывающе.
— Да, но оставайтесь со мной здесь, это не просто какой-то скучный старый документ.
— Ладно, это настоящий портал в прошлое.
— Да, мы должны были поиграть в детектива и собрать воедино то, каким был российский фармацевтический мир, знаете ли более десяти лет назад,
— Как маленькая капсула времени.
— Да, полная подсказок о том, как всё раньше работало.
— Ладно, название: "Требования к программному обеспечению для системы управления регистрацией лекарственных средств"
— Ок
— Нет, точно будет бестселлером с таким названием.
— Что внутри. О, вот где становится интересно. В основном это описывает программное обеспечение, которым они хотели заменить свою существующую систему для управления регистрацией лекарств. Из того, что мы можем сказать, их старая система, вероятно, была кучей электронных таблиц, и ручных процессов.
— О, я могу только представить себе эту головную боль!
— Да, эта новая система должна была упростить, все объединить в цифровом виде, так что представьте это, вы знаете, вы зарегистрировались в 2010 году, вы просто тонете в бумажной работе, пытаясь отслеживать каждую мелочь для каждого препарата в процессе разработки, и тут появляется эта система, и берет на себя тонны данных: про каждый препарат, категорию, дозирование, упаковку, научные данные.
— Там куча данных!

и т.д. в таком же духе на 19 минут :)

Вот ссылка, извините, что Youtube: https://www.youtube.com/watch?v=vOFn6p9qx6o

Это сделано в NotebookLM от Google, ну это больше шутка, конечно (хотя можно проверить — что AI вычитывает в вашем документе и где есть пробелы — например, тут они гадают, что за роль такая "гость", и кто бы это мог быть). А вообще в него можно загрузить несколько документов и ссылок, и задавать разные вопросы к этим документам — удобная вещь для аналитика при анализе нормативки, например, или старой документации.

Продолжение истории про 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 (это те, что "по специальности"). Удивительно тут, конечно, что по системному анализу и управлению требованиями книг тут не так много — даже не понятно, откуда я этого всего нахватался.