Признаться, раньше не слышал про https://mockintosh.io/ . Многим он подойдет лучше, чем Mountebank или WireMock, учитывая, что тестировщикам ближе Python. Правда, давненько коммитов уже не было.

Что используете вы для изоляции тестовой среды сервиса?

Очень интересна неоднозначная реакция на предыдущие посты. Хотя описанное явление известно под названием "Larman's Laws of Organizational Behavior".

Gregor Hohpe описывал это в статье "Reversing the disablement cycle: Everyone does the right thing, yet nothing much gets done. How to break self-reinforcing bad habits."

И есть очень качественный русскоязычный ресурс по этой теме: "Что такое сопротивление изменениям и как с ним работать?"

На эту тему у меня была заметка о том, как осуществлять изменения в коллективе.

С днем рождения меня, дорогой! 🍾🎂🥂🎇🎊🎉
https://www.tgoop.com/emacsway/s/6

Алина Богачёва @mialinist подготовила очередной раздел Systems.Wiki на тему

Generative AI for Analysis & Design

в раздел попали материалы:

1. Список нейросетей

2. Бизнес-анализ и требования
Анализ информации
— Обработка интервью
— Обработка анкет
— Анализ законов

3. Системный анализ и требования
Техническое задание
— Описание функциональных требований к системе
— Описание юскейсов
— Описание ограничений системы

4. Моделирование и диаграммы
Генерация схем
Генерация UML-диаграмм

5. Интеграции
Создание сценариев интеграции
Создание API-запросов
— REST API
— SOAP

https://systems-wiki.notion.site/Generative-AI-for-Analysis-Design-14b8db9e4167808eac30de6d5740dc03

Обсуждаем кейсы применения GenAI в группе @genai4AnD

💬 "Как только мы почувствовали гнев во время спора, мы уже спорим не за истину, а за себя." -- Карлейль

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

💬 „Всем известно, как тихи кладбища. Библиотека – самое веселое из них. Тут уж покойники в полном составе: они не сделали ничего плохого, лишь писали… От книги исходит аромат склепа. Вот тут начинается странный процесс, которую он называет чтением. С одной стороны, это обретение: он передает свое тело мертвым, чтобы они могли ожить. С другой – это общение с потусторонним миром.“ — Жан-Поль Сартр

Источник: https://ru.citaty.net/tsitaty/641057-zhan-pol-sartr-vsem-izvestno-kak-tikhi-kladbishcha-biblioteka-sam/

Как любил повторять один известный исторический деятель - «короче», «яснее». Вот это видео очень хорошо демонстрирует этот принцип:
https://vt.tiktok.com/ZS62A4GXs/

Примерно так же должен изъясняться и архитектор. Обратите внимание на отсыл к Закону Миллера в этом видео, и на акцент на визуализацию.

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

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

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

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

Рассчитывал на Locust, но обнаружил, что asyncio там не поддерживается и его поддержка пока не предвидится.

Нашелся нагрузочный микро-движок, который выручил: https://molotov.readthedocs.io/

После двух лет забвения по причине личных обстоятельств, наконец-то возвращаюсь к привнесению общественно-профессиональной пользы.

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

Началось все с создания генератора объема фейковых данных (см. здесь и здесь) для микросервисов, который воспроизводил бы селективность индексов как в целевой системе.

При этом все зависимые объекты создаются автоматически, а вероятностная распределенность их внешних ключей соответствует селективности индексов целевой системы.

Поддерживаются композитные ключи (первичные и внешние). Вероятностная распределенность поддерживается как для композитного ключа целиком, так и для составляющих его ключей.

Поддерживается логика многоступенчатого создания агрегата (black-box), когда агрегат возможно привести в необходимое состояние только серией запросов через public API.

Скажу честно, что я не смог бы этого сделать, не будь за моими плечами четырех собственноручно написанных ORM на четырех разных языках программирования и пяти фейкеров. Полученный опыт оказался бесценным.

Конечно, писать свой ORM архитектору может и нет практической необходимости, но в чем я сейчас твердо убежден, так это в том, что успешность архитектора немыслима без нагрузочных fitness-functions. А там практические навыки применения PoEAA оказываются на вес золота, независимо от того, создаете ли вы ORM или генератор фейковых данных. И наивно полагать, что эта задача посильна рядовому программисту. Если вдруг где-то специалисты с такими навыками и засиделись на позиции программиста, то будьте уверены - долго они на этой позиции в такой компании не задержатся. Это к вопросу о том, должен ли уметь архитектор в код.

Вскоре мы обнаружили, что полученный генератор данных можно использовать и для нагрузочных тестов. Адаптировали его для работы с публичным API (вместо прямого доступа к БД), сделали поддержку multiprocess.

Интегрировали его с нагрузочным движком molotov. Изначально рассчитывали на Locust, но обнаружили, что asyncio там не поддерживается и его поддержка пока не предвидится. Позже я узнал от @nkhitrov, что решение все-таки есть.

Потом мы обнаружили, что полученное решение можно без труда использовать для Out-of-process Component (Acceptance) Testing.

Таким образом, нам удалось сделать тестовый фреймворк (на Python), который позволяет одновременно и генерировать фэйковые объемы данных, включая автоматическое создание всех зависимых объектов, и создавать нагрузочные скрипты, и выполнять component out-of-process tests.

Теперь хотим завернуть его в Gherkin, чтобы fitness-functions в нем описывать. И добавить декларативное описание моделей посредством YAML-file.

Свои функции он уже выполняет. На текущий момент исходный код проприетарен. В перспективе возможно его раскрытие (обсуждается с владельцем кодовой базы) или оказание услуг нагрузочного тестирования сторонним ИТ-компаниям.

Работаем!

Может кому-нибудь пригодится для Out-of-process Component (Acceptance) Testing:
https://github.com/litestar-org/polyfactory

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

Добавил поддержку Gherkin для реализации Fitness-Functions в Performance Framework. Теперь описание Fitness-Function выглядит примерно так:

  Scenario: Some object endpoint name
    Given SUT with 10000000 objects
    When 100 processes created 10000 objects each
    Then average RPS is greater than 1000
    And error rate is less than 5%

Реализация подобного сценария посредством behave с использованием Performance Framework занимает всего 40 строк кода (половина из которых - это пустые строки и переносы строк для форматирования). Все зависимые объекты в БД создаются автоматически с сохранением селективности индексов целевой системы (включая индексы внешних ключей зависимых объектов). Подробная статистика запросов накапливается на сервере статистики. В перспективе, при наличии благоприятной возможности, может быть добавлена поддержка декларирования вероятностной распределенности зависимых объектов и проиндексированных значений непосредственно в Gherkin-спецификации.

Материала по этой теме накопилось на полноценный доклад (если даже не на целую книгу). Подумаю об этом.

Eще несколько решений, способных облегчить Out-of-process Component (Acceptance) Testing:
- https://schemathesis.readthedocs.io/
- https://hypothesis.readthedocs.io/
- https://github.com/python-jsonschema/hypothesis-jsonschema
- https://pypi.org/project/hypothesis-sqlalchemy/
- https://dredd.org/

Сколько вы знаете способов передачи данных на клиент по инициативе сервера?

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

Я насчитал 6 (добавляйте, если знаете ещё):

1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.

2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.

3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.

4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).

5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.

6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.

Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.

На самом деле, внутри GraphQL либо WebSocket, либо multipart subscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).

А  стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.

Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.

Есть такое модное понятие, применительно к медиа —фактчекинг. То есть, поиск и проверка источников. У аналитика это должно срабатывать на уровне рефлекса: кто-то сказал — нужно проверить и найти подтверждение, что это действительно так. Особенно интересно бывает найти нормативный документ, и увидеть, что практика с ним серьёзно расходится.

И у меня этот рефлекс часто срабатывает в обычной жизни. Иногда находится прекрасное.

Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно:
"Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%."

Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать.

Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг.

То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.

🧐Вон Вернон, написавший известную красную книжку про DDD Реализация методов предметно-ориентированного проектирования (а потом и зеленую книжку с подзаголовком Самое основное), пару месяцев назад запустил видеоблог под названием Design Accelerator

Недавнее видео Publishing Events From Legacy показалось мне примечательным. С технической точки зрения вы вряд ли узнаете в нем что-то новое. Но вот то, что DDD появляется в контексте модернизации унаследованных приложений, кажется мне интересным фактом. Похоже, мы возвращаем к дискуссии про Monolith First

Пару недель назад у Ivar Jacobson появилась бумага с названием Use-Case 3.0 и даже прошел вебинар (запись можно посмотреть здесь)

Я напомню, что концепция Use-Case 2.0 была о том, как организовать итерационную инкрементальную разработку посредством разделения сложного варианта использования на ломтики (slices) (Почитать можно здесь)

Что принципиально нового принесла версии 3.0 я пока так и не разобрался. Но, несмотря на это, варианты использования à la Alistair Cockburn/Ivar Jacobson остаются полезным способом описания сложных сценариев взаимодействия между системами/сервисами и разного прочего поведения