🔷 "SAGA — эволюция и новые смыслы" / Геннадий Круглов @GKruglov:
- https://news.1rj.ru/str/ru_arc/165

Хочу оставить свою рецензию.

Что такое архитектурное решение? Его суть сводится к тому, чтобы бесконечно большое множество вариантов реализации сократить до одного единственного варианта. Иными словами, архитектура - это о том, как не надо делать. И здесь важно не многообразие вариантов само по себе, а те критерии, по которым их количество можно сократить.

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

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

Вот об этом доклад Гены.

Какую проблему решала SAGA? А транзакция? А атомарность? А SAGA - это транзакция? А SAGA атомарна? Почему?

Вот Sam Newman утверждает, что SAGA неатомарна, а Chris Richardson - наоборот, что она атомарна. Вероятно, кто-то из них не стал утруждаться исследованием вопроса, но кто же из них прав?

Гена зацепил довольно сложную тему, сложность понимания которой привело к такому бардаку вокруг этой темы. Каких только заблуждений по этой теме мне не приходилось слышать: и то, что SAGA - это stateless, в отличии от Process Manager, и то, что она обязана иметь компенсации, и т.д.

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

Материал презентации содержит сотни человеко-дней исследовательской работы, и стал возможным исключительно благодаря консолидации опыта специалистов сообщества. И мой вклад тоже отражен в этом докладе, но особенно ценным оказался вклад @beer_Roman .

Вот только малая часть агрегации информации по этому вопросу из чата @ru_arc_chat :
- https://news.1rj.ru/str/ru_arc/112

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

Конечно, хотелось бы вместить больше в этот доклад, и есть что в нем улучшить.

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

Гена зацепил еще одну, не менее важную проблему - вопрос эволюции явления. Изменяется исторический контекст. Старые понятия утрачивают историческую актуальность. На их основе возникают новые понятия. Должны ли мы наделять старые термины новым пониманием? Вот в Agile начали возвращаться проектные практики, в силу изменения исторического контекста, - он перестал быть Agile? Вот SAGA стала решать проблемы распределенных систем, а не LLT - она перестала быть SAGA? А если она стала хореографической - она остается быть SAGA? Вот появились уровни зрелости CQRS - нужно ли изменить его определение, чтобы включить в него CQS?

Кажется, первый луч света в этом тумане неразберихи начал уже пробиваться.

Текущий состав Комитета РОО "Объединение ИТ-Архитекторов" на ArchDays'22:
@emacsway , @elukianov , @GKruglov , @sergey486 .

Надеюсь, что с 10 декабря этот состав расширится.

@elukianov и @GKruglov выступили с докладами. Свою рецензию на один из них я приводил в предыдущем посте.

Неофициальная часть после ArchDays'22. Обсуждение SAGA затянулось до 4-х утра... 🙂 В общем, к утру хореографический вариант SAGA нам с @GKruglov показался более убедительным 🙂)

EventStorming для документирования архитектуры нередко применяется даже в литературе, но теперь с этой целью вполне можно использовать PlantUML Activity Diagram (Beta):
- https://plantuml.com/en/activity-diagram-beta

Подробнее о нотации:
- https://www.uml-diagrams.org/activity-diagrams.html
- https://www.uml-diagrams.org/activity-diagrams-reference.html
- https://www.uml-diagrams.org/activity-diagrams-examples.html
- https://www.uml-diagrams.org/activity-diagrams-controls.html

P.S. Я уже говорил в сообществе, что предпочитаю для этих целей ArchiMate "C.1.10 Business Process Cooperation Viewpoint", нотация которого практически 1:1 совпадает с EventStorming, хотя в C4Model для подобных целей предусмотрена "Dynamic diagram".

C4Model + EventStorming удачно сочетаются в документировании Agile Architecture средствами Archi.

#EventStorming #UML #Documenting

1. Организации устроены таким образом, чтобы избегать изменений структуры власти, статуса-кво между топ- и средним менеджментом, а также между средним-менеджментом и специалистами.

2. Первое следствие из п.1 – любая инициатива по изменению будет сведена к переопределению существующей либо к вводу новой терминологии, по сути означающей то же самое, что и до изменений, но позволяющей поддерживать статус-кво.

3. Второе следствие из п.1 – любая инициатива по изменению будет высмеяна как «пуристическая», «теоретическая», «излишне революционная» и «требующая приземления на реалии организации», что мешает началу работ по устранению существующих проблем и сохраняет статус-кво руководителей и специалистов.

4. Третье следствие из п.1 - если после внедрения изменений некоторые менеджеры и специалисты не нашли себе места, то они становятся “коучами/тренерами“ в рамках этих изменений, часто усиливая влияние п.2 и п.3.

5. Культура определяется структурой (следует за ней).

- https://less.works/ru/less/structure

Illustrated Essential Kanban Condensed Notebook
https://kanban.university/illustrated-notebook/

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

Куда я пропал?

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

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

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

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

Сегодня очень нужен грамотный тестировщик, со знанием средст автоматизации e2e, CDC, out-of-process component tests (и средств изоляции - Mountebank, Wiremock), ATDD и BDD тестов. Желателен опыт в IoT.

Обращайтесь в личку: @emacsway

Потребность в кадрах постоянная, т.к. количество проектов постоянно растет. Только в этом году нужно запустить как минимум 12 проектов, что означает быстрый карьерный рост, т.к. будем выстраивать уровни управления Program Management и Portfolio Management. На среднесрочном горизонте просматривается около 90 проектов.

[UPDATE]: Москва, возможна удаленная работа.

[UPDATE2]: Канал сохранит свою тематику. Скоро вернусь к публично-общественной деятельности. Работа над Reference Application будет продолжена.

конкурент ChatGPT от Google - LaMDA: https://blog.google/technology/ai/lamda
————————
LaMDA’s conversational skills have been years in the making. Like many recent language models, including BERT and GPT-3, it’s built on Transformer, a neural network architecture that Google Research invented and open-sourced in 2017. That architecture produces a model that can be trained to read many words (a sentence or paragraph, for example), pay attention to how those words relate to one another and then predict what words it thinks will come next.
————————
оказывается, Google заоупенсорсил нейронку Transformer в 2017, а OpenAI её доработал )). и стал конкурентом гуглу (в конкретной нише) )).
————————
супер респект гуглу. я его за это уважаю. он двигает оупенсорс, и тем самым развивает всю индустрию. пофик даже, что сам себе конкурентов рожает. точно, достойно уважения.
————————
(не относится к делу)
IBM, кстати, такой же - серый кардинал всей индустрии и всего прогресса, который тут происходит. их несколько - таких кардиналов.
————————
(ну и, возвращаясь к гуглу)
Google ещё, тоже, вкидывает в Deepmind Flamingo - наблюдает за "успехами". и потом будет смотреть: "что и как".
в Hadoop такой подход назывался - Speculative Execution. а у дедушки Фаулера - Sacrificial Architecture )).
————————
ну и итог:
у каждого крутого вендора есть свой аналог. у гугла - speculative execution (sacrificial architecture): BERT, Transformer-XL, LaMDA, Deepmind Flamingo.

https://www.infoq.com/presentations/automation-testing-architecture
прикольно Владик разложил про тестирование архитектуры ))

🔷 The Web API Checklist -- 43 Things To Think About When Designing, Testing, and Releasing your API
https://mathieu.fenniak.net/the-api-checklist/

💬 Однажды Петька спросил у Василия Ивановича: В чём разница между идеологией, логикой и философией?

— Видишь, Петька, вон идут чистый и грязный. Кто из них пойдёт в баню?

— Ну, грязный.

— Нет, Петька. У грязного идеология быть грязным, а у чистого — быть чистым. Грязный в баню не пойдёт. Чистый пойдёт в баню.

— А логика?

— Видишь они уже поближе — чистый и грязный. Кто из них пойдёт в баню?

— Ну, чистый.

— Зачем же чистому идти в баню — он и так чистый. Грязный пойдёт в баню.

— А философия?

— Вот они уже подошли — чистый и грязный. Кто из них пойдёт в баню?

— Ну, грязный … нет чистый … нет грязный… не знаю что и думать, Василий Иванович.

— Вот это и есть философия.

Обратите внимание на то, что Петька, столкнувшись с трудностью в решении, кто пойдёт в баню, переходит от чистого и грязного к самому мышлению — «не знаю что и думать». Именно мышление не о чистом и грязном, а о самом мышлении (о чистом и грязном), Василий Иванович охарактеризовал как философию. Вслед за Василием Ивановичем, мы зададим сущность философии как мышление о мышлении о мире.

— Виталий Яковлевич Дубровский:
Введение в общую теорию деятельности. Лекция 1. Введение в системо-деятельностный подход

https://gtmarket.ru/library/articles/6554/6555

Task-based UI - примеры реализации клиентского кода для CQRS:

1. Vue:
- https://github.com/PacktPublishing/Hands-On-Domain-Driven-Design-with-.NET-Core/tree/master/Chapter13/src/Marketplace/ClientApp/src

2. Angular:
- https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src/Web/WebSPA/Client/src/modules/orders

3. React:
- https://github.com/kgrzybek/modular-monolith-with-ddd-fe-react/tree/main/src
- https://github.com/bespoyasov/frontend-clean-architecture/tree/master/src

4. С#:
- https://github.com/vkhorikov/CqrsInPractice/tree/master/After/src/UI
- https://github.com/vkhorikov/DddInAction/tree/master/DddInPractice.UI

5. .NET MAUI:
- https://github.com/dotnet-architecture/eshop-mobile-client

#CQRS

The state of JS 2022 - frontend frameworks:
- https://2022.stateofjs.com/ru-RU/libraries/front-end-frameworks/

#Frontend

Инструменты принятия решений: https://untools.co

#Management

Коллеги, хочу подискутировать с вами. Нужны ли агрегаты (доменные модели защищенные инвариантами) на фронте? Пишите свои выводы в комментариях.

Три статьи о функциональной доменной модели:
- https://bespoyasov.ru/blog/domain-modelling-made-functional/

(ссылки на продолжение см. внизу статьи).

[UPDATE]: Признателен авторам, которые делают свои знания отчуждаемыми:
- https://github.com/bespoyasov/www

Форкнул себе.

#FP #DDD

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

Основные требования:

1. Опыт сбора нефункциональных требований к ПАК. Не только к ПО, но и к железкам с камерами (IoT).

2. Опыт разрешения противоречий требований и поиска компромисов. Взвешивание инфлюенсиров.

3. Опыт обоснования архитектурных решений (дивергентная и конвергентная фаза) и их документирования.

4. Опыт проектирования распределенных систем. Знать, чем отличается Causal от Eventual Consistency, что такое векторные часы и какую проблему они решают.

5. Опыт в IoT. Хотя бы знать чем отличается MQTT от AMQP.

6. Опыт в DDD.

7. Опыт моделирования и декомпозиции с помощью Event Storming.

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

Москва. Возможна полная удаленка или гибрид. В офисе тоже можно.

Если выявлено неполное соответствие - все равно обращайтесь, обсудим.

Контакты: @emacsway

Зарплата в рынке. Проекты городского масштаба Москвы.

Спасибо)

Неплохое введение в архитектуры нейронных сетей:
- https://habr.com/ru/company/oleg-bunin/blog/340184/

Не так ново, правда, но неплохо. Дает хороший кругозор по этому вопросу.

#AI