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

Программист тратит на написание кода не более 5% времени.

I Know What You Did Last Summer
An Investigation of How Developers Spend Their Time
Roberto Minelli, Andrea Mocci and Michele Lanza
REVEAL @ Faculty of Informatics — University of Lugano, Switzerland
https://www.inf.usi.ch/faculty/lanza/Downloads/Mine2015b.pdf

#SoftwareDesign

Вы заметили, что среди архитекторов часто разгораются дебаты на тему "должен ли уметь архитектор кодить"?

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

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

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

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

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

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

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