Вот, кстати, отличная статья Анны Овзяк про проектирование интеграций: https://habr.com/ru/companies/alfa/articles/770184/

Там подробно, с чек-листом, расписано, как при проектировании интеграции идти от юскейсов пользователей, и как прорабатывать архитектуру интеграций при помощи модели C4.

Попал вчера аж в Центральный дом ученых на разговор про современное образование.

И вот какая там мысль проскочила (в связи с ИИ, куда же без него): формула образования — KSA, knowledge-skills-attitudes, знания-навыки-отношение (чувства, эмоции, убеждения, ценности). Причем attitude — это не soft-skills, это вообще не skills. Это то, что мотивирует человека применять тот или иной skill. (Поэтому я не очень люблю разговоры про софт-скиллы, они замещают разговор о ценностях и выборе поведения). Я про эту тройку уже как-то писал в канале — какие качества нужны аналитику.

Так вот в связи с ИИ высказывалось предположение, что знания человек может получить опосредовано — например, из книг или видео. Навык может быт натренирован частым повторением (тут дело быстрее идёт, когда тебя корректируют, но корректировать необязательно должен человек — если вам знакома зелёная сова, то она отлично с этим справляется при изучении языков), а вот сформировать ценности и убеждения в нас могут только другие люди: родители, друзья, среда, наставники в профессии. И вот эту среду ни ИИ, ни цифровые технологии нам организовать пока не могут. Поэтому цифровое обучение вполне эффективно при формировании knowledge и skills и почти не способно сформировать attitudes (т.к. не образует среды и образца поведения).

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

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

Давно не писал про ChatGPT. Но и новостей особо нет, работает привычно-штатно. Бросить в него алгоритм взаимодействия, построить диаграмму последовательности — уже на автомате. Кстати, он теперь сам начал подсказывать, куда её вставить (почему-то рекомендует PlantText.com)

Из нового: попробовал составлять руководство пользователя. Отлично получается.
Что можно делать:
➡️ преобразовывать в ГОСТовскую структуру неформальное описание (например, разработчик, как смог, описал; или из требований сделать руководство).
➡️ составлять руководство на основе кода или скриншотов(!) — а вот это новое, правда, доступно только в 4 версии.

Запрос:

Я создал интернет-сайт на тему <...>. На сайте размещены статьи по разным аспектам этой темы, пользователи могут регистрироваться, проходить опросы и добавлять комментарии под статьями.

Мне нужно составить руководство модератора по следующей структуре:
1 Введение
1.1 Область применения
1.2 Краткое описание возможностей
1.3 Уровень подготовки пользователя
1.4 Перечень эксплуатационной документации
2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
2.1 Виды деятельности, функции
2.2 Программные и аппаратные требования к системе
3 ПОДГОТОВКА К РАБОТЕ
3.1 Запуск системы
4 ОПИСАНИЕ ВЫПОЛНЕНИЯ ОТДЕЛЬНЫХ ОПЕРАЦИЙ
4.1. Наименование операции
4.2 Условия выполнения операции
4.3 Подготовительные действия
4.4 Основные действия
5 АВАРИЙНЫЕ СИТУАЦИИ

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

Генерация руководства по коду страницы:

На странице сайта есть комментарии. Вот код страницы с комментариями: <html-код, сколько влезет в промпт>
Напиши инструкцию модератора для работы с комментариями.

Результат:

4.4.9. Управление комментариями

4.4.9.1 Наименование операции: Управление комментариями.

4.4.9.2 Условия выполнения операции: Модератор имеет доступ к административной зоне сайта.

4.4.9.3 Подготовительные действия: Модератор переходит на страницу с комментариями.

4.4.9.4 Основные действия:
- Просмотр комментариев:
Модератор просматривает все комментарии на странице, обратив внимание на текст, авторов, дату и рейтинг комментариев.

- Редактирование комментариев:
Если необходимо внести изменения в комментарий, модератор выбирает соответствующий комментарий и нажимает на кнопку "Редактировать." Затем модератор вносит необходимые изменения в текст комментария и сохраняет изменения.

- Удаление комментариев:
Если какой-либо комментарий нарушает правила сайта или несет в себе ненадежную информацию, модератор выбирает этот комментарий и нажимает на кнопку "Удалить." Комментарий будет удален.

- Ответ на комментарии:
Модератор может отвечать на комментарии, нажав на ссылку "Ответить" под комментарием. После этого модератор может написать ответ в текстовом поле, и ответ будет опубликован после сохранения.

4.4.9.5 Описание блока комментариев
Блок комментариев представляет собой прямоугольную область на странице под статьей или записью.
Верхняя часть блока содержит заголовок "Комментарии" и количество комментариев (например, "2" в данном случае).

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

Каждый комментарий имеет следующие элементы:
- Аватар (изображение пользователя).
- Имя пользователя.
- Текст комментария.
- Дата и время добавления комментария.
- Действия с комментарием (ответить, редактировать, удалить).
- Рейтинг комментария (положительный и отрицательный).

Ниже списка комментариев расположена форма для добавления нового комментария. Форма включает следующие элементы:
- Поля для ввода имени пользователя и email (возможно скрыты).
- Текстовое поле для написания нового комментария.
- Кнопки "Сохранить" и "Отменить" для отправки или отмены добавления комментария.

А вот это уже интересно: составление описания и инструкции пользователя по скриншоту экрана! Доступно только в платной подписке GPT 4, но зацените уровень "чтения" картинки.

Конечно, по скриншоту можно составлять не только инструкцию пользователя, но и, например, команды для RPA, или попросить составить модель данных/сценарий при реверс-инжиниринге и восстановлении требований.

А вот генерация интерактивных прототипов из... да из всего генерация! хоть из мокапа, хоть из диаграммы состояний

Коллеги из Systems.Education перевели одну из провокационных статей Пола Ральфа: "Иллюзия требований при разработке программного обеспечения". В свое время немало споров она вызвала.

Ральф там высказывает две философские проблемы, связанные с понятием "требование":
1) онтологическую, проблему существования: а существуют ли вообще требования в смысле "неотъемлемые свойства решения, каким бы оно ни было", то есть то, что должно быть в любом случае реализовано, при любом выбранном способе решения. Из чего следует вторая проблема:
2) эпистемологическая, познавательная: а можем ли мы быть уверены, что мы рассмотрели все возможные варианты решения? А вдруг есть решение, которое мы не учли, и в котором вообще не будет нужды в тех свойствах, которые мы зафиксировали как требования?

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

А вы что думаете? Выносите ли вы для себя какие-то выводы из статьи? Это просто теория и заумный разговор о словах, не имеющий практического смысла, или поставленные вопросы как-то меняют всё понимание того, чем мы в индустрии занимаемся?

Как удалить Яндекс?

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

В этот раз на интеграциях дорогие участники спросили — а что будет, если мы попробуем удалить yandex.ru? Ну, в смысле, отправим в http запросе не GET, а DELETE? Ну и мы начали удалять всё подряд! 😂

И вот как по-разному серверы обрабатывают такой запрос:
👉🏻 yandex.ru на любой запрос отвечает: 200 OK, и выдаёт свою страницу. Получить? OK. Удалить? OK, вот вам наша страница. Запостить? OK, вот вам опять наша страница, почитайте. (Тем более, что по адресу yandex.ru сейчас отвечает dzen. Вы читайте, читайте).

👉🏻 google.com по-честному возвращает 405 Method Not Allowed и страницу с ошибкой.

👉🏻 trello.com, который мы используем для отработки вызовов API, возвращает 404 Not Found, что немного странно. По GET возвращает главную страницу, а DELETE — уже не найдено, спрятал.

И, наконец, vk.com выдаёт мою любимую 418 I'm a Teapot! Буду знать теперь, на каком примере её показать. Хотя конечно, строго говоря, в RFC 2324 и протоколе HTCPCP (Hyper Text Coffee Pot Control Protocol) никакого метода DELETE нет, а есть только BREW.

А вы как проектируете выдачу ошибок в http API?

Ну вот, в Zoom появился встроенный AI-суммаризатор разговоров, вот теперь мы всё узнаем о содержательности и смысле наших совещаний 😂😂😂

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

Следующим шагом, наверное, будет AI-модератор, чтобы человечишки всё-таки приходили к каким-то решениям :))

(Картинка из поста https://www.facebook.com/kuzmenko.kira/posts/pfbid0Fd4VRYVWqan3iiRz2Mz85JUBJBCAQBevDHJvHMdmjRQbPAkd9ZHb2uYvWtpLu2mSl)

Шикарная шпаргалка по различным стилям и протоколам API от Алекса Сюя (Alex Xu) и Postman.

Это именно протоколы, стили и архитектуры, поэтому конкретных решений тут нет (а где же Kafka и RabbitMQ? Они в EDA и AMQP, соответственно).

В статье текстом подробно описаны преимущества и недостатки каждого стиля и протокола.

В принципе, это уже половина готового курса по технологиям API, дальше гуглить вглубь, если нужно подробнее разобраться.

Ссылка: https://blog.postman.com/api-protocols-in-2023/

Осенью на Infostart Tech Event меня попросили рассказать про уровни требований: все эти BRS, SRS и так далее.

Вообще я не очень люблю эту историю с пачкой многоуровневых документов, но в двух случаях она оправдана:

1) Если вы их разрабатываете последовательно, и перед переходом к более детальному документу принимаете решение: идём дальше или нет? А ещё, по-хорошему, рассматриваете несколько вариантов, и выбираете из них. Тогда вам нужен предыдущий документ, чтобы вернуться к нему — начать заново или проверить соответствие.

2) Если команда между документами меняется. Это не очень хорошая история, но бывает. И документ тут — не самый лучший вариант, но уж какой есть, иногда только так.

И, уж если вы всё-таки разрабатываете эти документы, как бы они не назывались, смысл их такой:
👉🏻 Что нужно?
👉🏻 Как делать будем?
👉🏻 Что в итоге сделали?
👉🏻 Как этим пользоваться?

И — как и почему в каждом случае принимали решения. А то иногда смотришь, и думаешь — wtf?! А у людей ведь мысль какая-то была.

В общем, держите всю презентацию, может пригодится.

Если вам нравится идея нарезки требований (решений) на уровни, то в Archimate есть, пожалуй, самая детальная нарезка в Layered Viewpoint, многослойном представлении архитектуры:

🟡 внешние акторы (клиенты, организации)
🟡 услуги, которые мы им предоставляем (бизнес-сервисы)
🟡 бизнес-процессы, при помощи которых предоставляются услуги
🔵 ИТ-сервисы, которые поддерживают процессы
🔵 прикладные ИТ-системы, которые предоставляют сервисы
🟢 Инфраструктурные сервисы, обеспечивающие работу ИТ-системы
🟢 Инфраструктура (оборудование, базовые ИТ-системы)

Ко всему этому можно на любом уровне приписать стейкхолдеров с интересами, мотивацией, ограничениями, требованиями, ценностями.

Вот эта разбивка на абстрактные сервисы, которые дают кому-то ценность, и конкретные системы, которые их предоставляют, очень понятна для архитектора и для многих руководителей (и я так много раз рисовал, даже ещё не зная, что в Архимейте это зашито в стандарте). Особенно заходит идея: как мы из разных сервисов будем собирать одну большую услугу/продукт, если их у нас много или они под каждый проект собираются уникальным образом. И какие мы будем в разных клиентских проектах использовать технологии для реализации одних и тех же сервисов: вот для этого проекта ещё по-старому вручную, вот для этого -- на прототипе -- nocode решении, а вот тут попробуем нашу новую платформу использовать.

Удобно это всё зафиксировать на диаграмме, чтобы все понимали свой маневр.