Системный сдвиг – Telegram
Системный сдвиг
10.1K subscribers
270 photos
8 videos
20 files
272 links
Авторский канал Юрия Куприянова. Обучаю системных аналитиков. Пишу про нетривиальные темы в анализе, проектировании систем, управлении и обучении.

Программный директор WAW, член ПК Flow, ЛАФ.

Контакты: @YuryKupriyanov

Курсы: https://systems.education
Download Telegram
Вообще я сегодня про другое хотел написать, но невозможно пройти мимо актуальной темы: буквально на наших глазах развернулась поучительная история: как Яндекс почти положил службу точного времени в Рунете.

Краткое содержание: с середины октября российские сервера точного времени (NTP) второго уровня, поддерживаемые сообществом (то есть, люди по собственной инициативе у себя их развернули на роутерах, на своих серверах), испытали практически DDoS-атаку — трафик на них катастрофически вырос, и люди стали их отключать. Из 140 серверов осталось 5. Оказалось, этот трафик посылают умные колонки от Яндекса, в которые с очередным обновлением прошивки приехал баг, заставляющий их слать запросы на синхронизацию времени каждые 5 секунд.

Обнаружил это один из участников пула NTP, и опубликовал 24 ноября статью на Хабре, чтобы привлечь внимание к проблеме. Сейчас Яндекс баг уже признал и исправил, и пообещал установить собственные сервера точного времени, а не полагаться на общественные.

Вопрос методический: чья эта область ответственности?

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

Яндексу в колонке точное время нужно для будильников, таймеров и календаря, а также для некоторых технических вещей.

И когда это устройство было экспериментальным — никто особенно не задумывался над серьезностью такого взаимодействия. Ну, сели на общий pool.ntp.org, который используется всеми линуксами и большинством устройств. Оно работает, и ладно.

Когда колонки стали продавать миллионами в год, это уже совсем другой уровень ответственности (ещё один вопрос из курса по интеграциям — с какой скоростью вы собираетесь масштабироваться?). Один непротестированный апдейт — и вся инфраструктура легла.

На мой взгляд, здесь есть три момента, которые относятся к задачам системного аналитика:

1. Анализ эффектов при масштабировании (рост нагрузки на смежные системы, превышение лимитов внешних API);
2. Анализ условий использования внешних систем (у проекта NTPPool есть гайдлайны для вендоров оборудования, им нужно следовать);
3. Контроль и учет всех входов и выходов системы (Сергей Нужненко рассказывал об этом упражнении на Flow).
🔥38🤔3🙏3
А написать я хотел про синхронные и асинхронные взаимодействия, по следам предыдущего (теперь уже пред-предыдущего) поста.

Андрей Бураков справедливо заметил, что WebSockets-то асинхронный, а я его в синхронные записал, вот позор.

Но логика у меня в этот момент была вот какая: если нам нужен быстрый отклик — мы берем паттерн "запрос-ответ", то есть RPC и REST. Но если нам нужен ещё более быстрый отклик — мы берём WebSockets, где взаимодействие асинхронное. Ну или используем Long Polling, WebHooks или MQTT — все они асинхронные, и все применяются, когда нам нужно очень быстро отреагировать на событие.

Следующий шаг в этом же направлении, но на другом уровне, сделал Google со своим протоколом QUIC, заменяющим TCP. Потому что установка соединения TCP — слишком дорогая и долгая операция, а делать её приходится почти при каждом запросе (да, есть keep-alive, тогда соединения будут держаться дольше, но у этого есть и обратная сторона — именно это соединение нужно использовать, пока оно живо. Иначе у вас будет много живых соединений и, соответственно, много занятых портов).

Протокол QUIC в основном ориентирован на веб-браузеры, а веб-браузеры имеют обыкновение запрашивать много разных ресурсов одновременно. Хотя каждый запрос сам по себе синхронный, выполняются они в java noscript'е асинхронно, через промисы и async/await, и про это есть много шуток у фронтендеров — очень больная тема, сложно понять.

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

Ну и как только нам не нужна мгновенная реакция, мы тоже используем очереди. Асинхрон, когда нам нужно быстро отреагировать, асинхрон, когда нам не нужно быстро реагировать.

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

По случайному совпадению, этот диапазон как раз соответствует человеческому восприятию "мгновенной реакции". Она как раз примерно от 100-120 мс у гонщиков F1, пилотов истребителей и топовых кибер-спортсменов, до 250-300 мс — у обычных людей. Можете проверить себя: https://humanbenchmark.com/tests/reactiontime , у меня как раз 253 получилось в среднем. Хорошее пятничное развлечение :)

Так случайно совпало, что типичные http-запросы выполняются как раз примерно за 300-900 мс (передача данных через websocket — 200 мс). Действий быстрее 13 мс человек вообще не воспринимает (скорость обмена в 5G-сетях — 15 мс, это быстро). Аукцион рекламодателей за рекламное место на веб-странице — RTB — занимает 100-200 мс. В высокочастотном трейдинге решение о сделке принимается за микросекунды. На таких скоростях важным становится расстояние между серверами, поэтому их ставят прямо в датацентре биржи или вообще втыкают прямо в PCI-шину биржевого сервера. Вызов обработчика прерываний вообще в тактах процессора считается — это наносекунды для современных компьютеров.

Такие скорости у нас. И в некоторых случаях становится принципиально, что действие происходит не мгновенно, а за конкретное не нулевое время.
👍158
На тренинге по интеграциям возник вопрос: что куда класть в http-запросе (в REST API). Решил разложить по полочкам (pun intended).

Полочек в http четыре штуки:

➡️ путьpath или route, эндпоинт, он же на жаргоне яндексоидов "ручка" (то, что после адреса сервера, за символом '/' — иерархия типов ресурсов и их идентификаторов. По аналогии с путем к файлу на диске, в пути говорят о вложенности — как будто каждый следующий уровень в цепочке '/' вложен в предыдущий. То есть, /orders/123456 — это заказ с id=123456, а /orders/123456/items — это перечень товаров в этом заказе, товары "вложены" в заказ)

➡️ параметры запроса, или query (то, что в конце URL, за символом '?' — перечисление параметров в формате имя=значение, разделенных &.)

Метод http, путь, параметры и версия протокола вместе называется называется строкой запроса или стартовой строкой. Строки запроса сохраняются в логах сервера.

➡️ заголовки запроса — http headers (передаются после строки запроса в виде пар "имя":"значение"). Обычно не сохраняются в логах, но иногда могут (можно настроить частичное сохранение — например, значение cookie или токенов точно не нужно сохранять, т.к. их можно использовать для выдачи себя за другого пользователя).

➡️ тело запроса — http body (тут понятно, это сами содержательные данные, которые мы передаем).

Есть из чего выбрать! Понятно, что идентификатор запрашиваемого ресурса мы обычно размещаем в пути, а содержимое помещаем в теле запроса (если это POST/PUT/PATCH). А если мы хотим указать связь нашего ресурса с другим? Например, связь заказов с клиентом? Тут уже могут быть два варианта: nested resources (вложенные ресурсы: /clients/689697/orders) или flat (плоские: /orders?client=689697, в API только пути с названиями ресурсов).

А если мы хотим указать версию API, у нас ещё больше вариантов: путь (/api/v1/orders), параметры (/api/orders?version=1) и заголовки (через кастомный заголовок: X-API-Version: 1, или через стандартный заголовок Accept: application/json; version=1 ). Я видел даже парочку случаев, когда версия передавалась в теле(!), даже для GET (хотя вообще сервер должен игнорировать тело GET-запроса).

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

Вопросы эти очень дискуссионные, я для себя выработал такие правила:

Путь — это указатель на коллекцию ресурсов или конкретный экземпляр. Лучше не тянуть туда ни версионность, ни фильтры, ни метаданные. Идентификатор в пути может быть только один (то есть, если мы описываем вложенные ресурсы, там может быть идентификатор на конце, или вторым от конца. Таким образом, вложенность будет только двухуровневая, и не будет диких URL типа /cities/77/pickpoints/35/clients/689697/orders/123456/items)

Параметры запроса — это ограничения на выдаваемую коллекцию ресурсов или набор полей одного ресурса. Поэтому тут будет простой поиск, фильтрация, набор полей в выдаче, пагинация, сортировка. То есть, это метаданные, относящиеся к ресурсу. Если мы хотим получить заказы клиента, доставленные в пункт выдачи с id=35, это будет выражено так: clients/689697/orders?city=77&pickpoint=35 (мы ограничиваем спискок заказов).

Заголовки — это метаданные запроса (а не ресурса). Это всё, что касается форматов выдачи (я видел API, в которых формат был зашит в путь: /api/xml/orders и /api/json/orders — не делайте так!), версии API и версии ресурса, кэша, параметров соединения, id запроса и т.п. Дискуссионный вопрос про пагинацию: её можно поместить и в заголовки тоже, как и ответную информацию (текущая страница, общее число страниц, число записей всего, следующая страница, предыдущая страница). Часто метаинформацию про пагинацию помещают в тело ответа, но, как по мне, это перегружает структуру ответа и может сделать её разнотипной для разных ответов — будьте с этим осторожнее.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍63
Тело — непосредственно сам ресурс или коллекция ресурсов. Метаданные о ресурсе лучше отдать в заголовках ответа, хотя я вижу часто подходы, когда метаданные отдают в одном json'е с содержательными данными, как например, в спецификации JSON:API. Там у них вообще в ответе сразу и данные (data), и ошибки (errors), и метаданные (meta), и ссылки (links), и вложенные объекты (included):
{
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"noscript": "JSON:API paints my bikeshed!"
},
"links": {
"self": "http://example.com/articles/1"
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/articles/1/author"
},
"data": { "type": "people", "id": "9" }
},
"comments": {
"links": {
"self": "http://example.com/articles/1/relationships/comments",
"related": "http://example.com/articles/1/comments"
},
"data": [
{ "type": "comments", "id": "5" },
{ "type": "comments", "id": "12" }
]
}
}
}],
"included": [{
"type": "people",
"id": "9",
"attributes": {
"firstName": "Dan",
"lastName": "Gebhardt",
"twitter": "dgeb"
},
"links": {
"self": "http://example.com/people/9"
}
}, {
"type": "comments",
"id": "5",
"attributes": {
"body": "First!"
},
"relationships": {
"author": {
"data": { "type": "people", "id": "2" }
}
},
"links": {
"self": "http://example.com/comments/5"
}
}, {
"type": "comments",
"id": "12",
"attributes": {
"body": "I like XML better"
},
"relationships": {
"author": {
"data": { "type": "people", "id": "9" }
}
},
"links": {
"self": "http://example.com/comments/12"
}
}]
}


Мне кажется, это уже перебор — каждый раз придется парсить ответ, чтобы вытащить оттуда нужное.

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

Let's discuss!
👍18🔥12
Сейчас будет сложный пост, я бы даже сказал — философский. На Flow в одном разговоре зашла речь о том, что различные документы и диаграммы — это разные проекции будущей системы. Мол, система многомерна и многоаспектна, и мы не можем её представить целиком, но можем создавать отдельные проекции, через эти проекции подсвечивать какие-то аспекты системы, и так приближаться к пониманию системы во всей ей полноте.

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

Мне кажется, в таком подходе есть большая доля идей позитивизма, даже логического позитивизма. Его адепты верили, что любое знание можно вывести и доказать либо путем эмпирических наблюдений (то есть, проверить на опыте), либо из логических правил и преобразований. Это идеи 20-30-х годов XX века, т.н. "Венский кружок". Дальнейшие разработки, в том числе членов кружка — Гёделя, например — привели к формальным доказательствам того, что истинность (и даже непротиворечивость) сложных систем доказать невозможно. Дальше больше — в квантовой физике обнаружился принцип неопределенности, в термодинамике — хаотические системы, в информатике — проблема остановки (принципиальная невозможность доказать — зациклится программа или выдаст ответ. в частности, это означает невозможность доказать наличие решений у некоторых уравнений).

Короче, мир оказался основанным на недоказуемых теориях, причем их недоказуемость оказалась строго доказанной!

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

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

Точнее, разработка прошла все этапы:

метафизику, то есть разговор об очень абстрактных понятиях, не имеющих строгого содержания ("требование", "решение", "проект", "система", "данные");

позитивизм (мы можем всё определить, логически выразить и формально доказать);

постпозитивизм в виде фальсифицируемости (не можем доказать правильность программы, но хотя бы можем сказать, что те функции на тех данных, что мы проверили, работают корректно — тестирование и BDD), конструктивизма (не существует абсолютной истины, мы конструируем подходящий нам результат в процессе совместной деятельности, постоянно проверяя результат опытом; важна структура этой деятельности — agile), и неопрагматизма (нечто, что мы называем, имеет смысл, пока это несёт для нас пользу в определенном контексте; нет описания реальности "вообще", есть описание под конкретную задачу — DDD).

Окончательно добивает остатки позитивизма современный подход к ИИ: оказывается, при помощи "грубой силы" и наращивания числа связей в сети можно гораздо лучше решать практические задачи, чем через построение абсолютной исчерпывающей модели (см. очень показательную историю последних лет компании Abbyy и их проекта Compreno — чем она закончилась, я думаю, вы все слышали).

Наглядно видно это и в истории REST, например — тот же HATEOAS очень оптимистично выглядит в теории, а на практике почти не применяется.

В общем, пост философский, и каждому нужно понять для себя — какие представления я кладу в основание своей картины мира? Метафизику, позитивизм, или современные подходы — лишенные идеального образца, но зато решающие задачу.
22👍9🔥8🤔6❤‍🔥3
Про версионирование API, по итогам нескольких обсуждений: очень сильно зависит, что у вас за API (внутреннее или внешнее), кто ваши клиенты и насколько вы зависите от них (или они от вас).

Например, если ваше API — внешнее, а клиенты сильно зависят от вас, и вы хотите, чтобы они быстрее переходили на новые версии API — бейте лампочки в подъездах ставьте версию API в путь и давайте окно для перехода (несколько месяцев). У клиентов не будет других вариантов, кроме как перейти на новую версию — иначе у них очень грубо сломаются все вызовы, будут выдавать просто 404. Зато не будет шансов, что будет пропущена ошибка или сломается логика из-за разных форматов. Умерла так умерла. Так делают facebook (экстремистская деятельность которой запрещена на территории РФ), twitter и tiktok.

Facebook дает 90-дневный период для перехода, а X обещает не вносить ломающих изменений чаще, чем раз в год.

Кроме того, указание версии в пути позволяет легко отследить число клиентов, использующих каждую версию, по логам. Также не возникает проблемы с кэшем — не случится так, что закэшировалась старая версия. Правда, в URL возникает постоянное мерцание, и их нельзя сохранять — для старых ресурсов они испортятся (вопрос — по логике вашего бизнеса, может ли у клиента возникнуть потребность долго хранить URL ресурсов?)

Доходит иногда до смешного: в API платежного сервиса Stripe, судя по всему, сначала собирались использовать версионирование через путь (/v1/), но потом перешли на хедер Stripe-Version, который переключает(!) версию API, используемую этим клиентом. Если вы отправляете запрос с этим хедером, сервер запомнит, какую версию вы использовали, и остальные запросы будет обрабатывать как к этой версии. Это уже хранение состояния на сервере!

А вот VK принимает версию в параметре, но этот параметр является обязательным. Так у вас не меняется путь, но замусоривается хвост URL. Зато можно добавить параметр для версии, если вы забыли про него с самого начала.

Чтобы не замусоривались URL'ы, а вы сильно зависите от ваших клиентов — лучше не менять URL'ы, и давать возможность указать версию в параметрах или в хедере. Все варианты с хедером добавляют дополнительных мыслей разработчикам — теперь им ещё и про хедеры нужно думать. Тут возникают риски поймать ошибку: во-первых, эту штуку с хедерами тяжело тестировать, во-вторых — если мы меняем все пути в приложении, то подумаем и про остальные изменения.

Ещё один аргумент пуристов RESTа, что обсуждение версии ресурса — это часть обсуждения типа контента между клиентом и сервером. Клиент сообщает серверу о версии контента, который может принимать клиент, поэтому версия должна быть в хедере Accept: application/vnd.myapi.v2+json

В этом смысле интересно услышать мнение Роя Филдинга про версионирование. Оно очень короткое:

DON'T

Чуть подробнее Филдинг обрушивается на версионирование через версию в пути:
a "v1" is a middle finger to your API customers, indicating RPC/HTTP (not REST)


А правильный ответ, конечно, HATEOAS (чего бы мы ещё могли ждать от Филдинга).
"hypermedia as the engine of application state" is a REST constraint. Not an option. Not an ideal. Hypermedia is a constraint. As in, you either do it or you aren’t doing REST. You can’t have evolvability if clients have their controls baked into their design at deployment. Controls have to be learned on the fly. That’s what hypermedia enables.


Типа, если вы меняете структуру ответов и даже API — выразите это в ссылках, через гипермедиа. А если у вас изменения, которые должны сломать всех клиентов — значит, у вас новая система, меняйте не версию API, а сразу доменное имя — ведь теперь это другая система, верно? 🤯🤦🏼‍♂️

Вот это уже шестой вариант версионирования — через имя домена. Ну действительно — меняем api.server.com на api2.server.com. Интересная мысль!
👍147🤨4🤔3
Учат ли системному анализу в школе? Оказывается, да! В 10-11 классах. Есть вот целый учебник.

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

Как думаете, поможет это в становлении системного аналитика? Оцените, кстати — на какую профессию там ориентируют школьников — генеральный конструктор, ни много ни мало!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А в следующий раз я расскажу о философских основаниях требований — там тоже интересно, не переключайтесь!
23👍6
Вам хотелось когда-нибудь озвучить ТЗ? Причем чтобы не просто диктор его зачитывал, а это звучало как-то более интересно? Теперь при помощи AI можно превратить документ в подкаст.

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

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

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

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

Это сделано в NotebookLM от Google, ну это больше шутка, конечно (хотя можно проверить — что AI вычитывает в вашем документе и где есть пробелы — например, тут они гадают, что за роль такая "гость", и кто бы это мог быть). А вообще в него можно загрузить несколько документов и ссылок, и задавать разные вопросы к этим документам — удобная вещь для аналитика при анализе нормативки, например, или старой документации.
🔥12
Продолжение истории про Mothers of All Demos — оператором видеокамеры на этом мероприятии был некий Стюарт Бранд — издатель журнала The Whole Earth Catalog, биолог, эколог и активист.

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

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

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

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

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

Вот так всё связано хитрыми способами!
👍9❤‍🔥7🔥3🤯2
Иногда интересные общеприменимые идеи встречаются в стандартах и фреймворках, принятых в отдельных отраслях.

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

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

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

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

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

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

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

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

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

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

Аналитик, особенно бизнес-аналитик, по моему убеждению занимается именно цифровизацией предприятия — может быть, не всего, а отдельных процессов, но в пределе — может и всего, как CDTO (директор по цифровой трансформации). Это к вопросу о возможном карьерном треке и кем может быть опытный аналитик, если не архитектором и не менеджером проектов.
🔥141
Мы всё неправильно понимаем про 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 должен работать на самом деле. Ясно, что он так практически никогда не работает, так что можете этими знаниями блеснуть на собеседовании, разве что. И то — будьте осторожны, а то интервьюер примет вас за зануду-теоретика, выучившего стандарты, но далекого от практики. А на практике ни один фронтендер не будет вам конструировать сложный патч-документ, когда можно передать просто набор изменившихся полей. Ну, или пока дело не дойдет до какого-то очень сложного по структуре, со многими уровнями вложенности объекта.
👍26🔥154
По сети, говорят, ходит флешмоб про 20 книг, которые до сих пор с вами или сильно повлияли на вас: без объяснения, только обложки.

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