Книга-квест "Ам Ням. Жми" (Рубрика #ForKids)

Вчера прочитал перед сном сыну эту книгу, в которой 20 небольших глав, а сегодня мы прошли все мини игры в дополненной реальности. Если кратко, то описание книги обещает раскрыть истинную историю появления Ам Няма, а потом Ам Ням спасет мир от супер-злодея из комптьютерной игры. Мне показалось, что это неплохая книга для дошкольников - весело и интересно, а родителям забавно читать про взаимоотношение Ам Няма и его "дамочки" сердца, Ам Няши, которую он спасает на протяжении всей книге.

P.S.
Книги от DEVAR нравятся нашим детям и у нас дома собрался из них полный комплект, а о некоторых я уже рассказывал: например, о "Живой раскраске Смешарики".

#ForKids #ForParents #Tales

The Golden Passport: Global Mobility for Millionaires (Золотой паспорт: Глобальная мобильность для миллионеров) (Рубрика #Economics)

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

Основные моменты книги включают:
- Исследование трансформации продажи паспортов от сомнительной практики до процветающей индустрии, в которую вовлечено более десятка стран. Интересно, что формально и в России есть программа гражданства через инвестиции, а глобальным лидером сейчас является Турция, которая перехватила лидерство у Кипра. В Карибском бассейне еще есть старожилы рынка инвестиционных паспортов в виде Сент-Китса, Гренады, Доминики, Сент-Люсии, Антигуа и так далее
- Анализ сложных причин этого явления, включая желание повысить глобальную мобильность, получить налоговые льготы и обеспечить страховку от политической нестабильности.
- Масштаб рынка - порядка 50к человек, что ежегодно приобретают гражданство через эти программы, стоимость зависит от программы, но начинается все с нескольких сотен тысяч долларов и может доходить до миллионов
- Исследование последствий этой практики для концепций гражданства, глобального неравенства и взаимосвязи между богатством и национальной принадлежностью.

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

P.S.
Это книга издательства Fortis Press, которая публикует переводы недавних интересных книг на актуальные темы. О парочке книг этого издательства я уже рассказывал раньше
- Woke, Inc. За фасадом корпоративной риторики о социальной справедливости (Woke, Inc.: Inside Corporate America's Social Justice Scam)
- Taming Silicon Valley: How We Can Ensure That AI Works for Us

#Economics #History

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part I (Рубрика #Architecture)

Вчера перед сном прочитал интересный whitepaper про процесс SAR (Software Architecture Recovery) при помощи LLMs. Мне идея показалась интересной, чтобы кратко рассказать про нее.

1) Стандартный подход к Software Architecture Recovery обычно работал снизу-вверх (bottom-up). Условно, некоторый анализатор кода запускался строил архитектурные метрики, которые как-то характеризовали архитектуру проекта (что-то в духе кейсов из книги "Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture", про которую я уже рассказывал)
2) В этом paper исследователи решили пойти сверху-вниз (top-down) и начать с задания референсной архитектуры, а дальше уже классифицировать части кода как относящиеся к той или иной части этой референсной архитектуры. Это позволяет не просто собрать текущее состояние архитектуры как было в стандартном подходе, а оценить расхождение между референсной архитектурой проекта и тем, что у нас есть на самом деле:)
3) Авторы говорят о том, что этот подход больше похож на то, как работают software engineers, так как обычно инженеры знают какая базовая архитектура в проекте, поэтому могут использовать эти знания при изучении кода

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

#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part II (Рубрика #Architecture)

Продолжая рассказ про дедуктивный процесс SAR (Software Architecture Recovery) при помощи LLMs, я расскажу своими словами про шаги этого процесса

Phase 1. Reference architecture definition - собственно, именно эта фаза добавляется авторами и позволяет потом добавить использование LLMs
1) Select reference architecture - здесь авторы предлагают выбрать референсную архитектуру, упоминаются стандартные layered architectuure, MVC, но сходу можно припомнить и другие подходы вида MVVM, Onion Architecture, ...
2) Define architectural components - здесь авторы определяют компоненты архитектуры, именно они будут использоваться LLMs для дальнейшей классификации кода. Например, для типовой layered architecture выделяются следующие уровни: presentation, application service layer и так далее
3)Define component & interaction indicators - здесь авторы в текстовом виде описывают правила взаимодействия компонентов, что дальше используется для классификации. Например, в случае с layered architecture авторы описывают свойства presentation layer

Pr1 . . sets the attributes of UI components, e.g., sets the text of a TextView.
Pr2 . . . notifies listeners about user events, such as button clicks or list item selections.
Pr3 . . . transforms domain objects into visual representations

Phase 2. Code unit classification - эта фаза рекурсивная и направлена снизу-вверх. Авторы предлагают выбрать гранулярность, а потом запустить классификацию. Например, начать с методов классов, дальше аггрегировать это в классы, потом в неймспейсы и так далее
4) Evaluate code units against indicators - собственно, здесь немного prompt engineering + код с описаниями методов попадает в LLM (GPT-4) на оценку для классификации по компонентам из референсной архитектуры

In a layered software architecture, one of the layers is the (layer_name) layer, which (layer_responsibility).
Consider the context of an Android Java project “(project_name)”:
(project_domain_description)
Here are some indicators that a Java method in the project may belong to a class in the (layer_name) layer:
(layer_indicators)
The class ‘(class_name)’ contains the method ‘(method_name)’:
(method_source_code)
Check whether this method satisfies each indicator above. Mention the specific line of code that supports your reason. At the very last
line, write the boolean verdicts separated by a comma, e.g., ‘true, true, false, true’. If indeterminate, say ‘false’.

5) Aggregate classified code units - здесь мы агрегируем ответы с прошлого этапа и получаем классы, в которых были методы, а дальше запускаем их на предыдущий шаг для повторной классификации и так пока не доберемся до нужного нам уровня абстракции

На выходе такого процесса у нас получается некоторая классификация программных компонент с учетом референсной архтитектуры нашего проекта. Авторы сделали PoC для Android приложения K9 Mail и сравнили ручную разметку экспертами с тем, что насчитала модель - precision и recall для классификации оказались 72% и 71% соответственно. В итоге, авторы отметили, что есть еще пространство для улучшений и сформулировали свой план дальнейших исследований, включающих в себя работу над референсными архитектурами, а также полевое исследование в компаниях с применением этого метода.

#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

The issue of monorepo and polyrepo in large enterprises (Рубрика #Architecture)

Недавно прочитал старенький whitepaper 2019 года от Nicolas Brousse из Adobe с анализом подходов к управлению репозиториями исходного кода в крупных компаниях. Собственно сравниваются подходы монорепозитория и полирепозитория (множества отдельных репозиториев). Монорепы используют такие компании как Google, Meta, Microsoft, а полирепозитории были в Amazon, Netflix, Lyft и так далее. Автор ссылается на исследование "Advantages and disadvantages of a monolithic repository: a case study at Google", в котором есть хорошее сравнение компромиссов монореп и полиреп и подсвечиватся плюс монорепы вида, что монорепы

Encourages consistent and high-quality code, and empowers engineers to study and learn from the institutional knowledge of their company, crystallized in the form of source code

Дальше автор рассматривает разницу через три призмы

1) Cultural Alignment (культурное соостветствие)
Структура репозиториев отражает корпоративную культуру. Монорепы подходят для коллаборативных сред (например, Google с философией «открытого сотрудничества»), а полирепозитории — для культур, ориентированных на автономию (например, Netflix с принципом «свободы и ответственности»). Интересно, что у нас полирепозиторий в Т-Банке
2) Team Cognition (командное познание)
Монорепозитории разрушают функциональные силосы, способствуя целостному пониманию задач за счёт видимости общего кода и снижения коммуникационных барьеров, что коррелирует с повышением качества софта.
3) Tradeoffs (компромиссы)
Обе модели имеют технические сложности (например, масштабируемость монорепозиториев), но монорепы стимулируют культурные изменения, улучшающие конкурентоспособность через DevOps-практики и инновации без ограничений.

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

P.S.
На тему различий рекомендую почитать сравнение от Carlos Arguelles, инженера, что долго проработал в Amazon на CI/CD инфрой, потом ушел в Google на несколько лет, а потом вернулся в Amazon. Я раньше уже разбирал его статью "How Amazon and Google view CI/CD in an entirely different way".

#CI #SRE #Architecture #Software #Infra #QA

Hooked: How to Build Habit-Forming Products (На крючке) (Рубрика #Management)

Эта уже классическая книга Нира Эяля рассказывает о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. В книге представлена модель крючка в виде процесса из четырех зацикленных шагов, что позволяют формировать привычки пользователей. В самой модели следующие четыре части
1) Trigger (триггер): запускает поведение пользователя через внешние сигналы (например, уведомления) или внутренние мотивации (эмоции или мысли).
2) Action (действие): поведение, выполняемое в ожидании вознаграждения, которое должно быть максимально простым для пользователя.
3) Variable reward (переменное вознаграждение): результат действия, который удерживает пользователей благодаря своей непредсказуемой природе.
4) Investment (инвестиция): вклад пользователя в виде времени, данных, усилий или денег, что повышает вероятность возвращения к продукту.

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

Используя эту модель, можно разобрать подходы известных продуктов

1) Duolingo создал формирующий привычку опыт изучения языков:
- Триггер: отправляет ежедневные уведомления о целях изучения языка.
- Действие: предлагает геймифицированные, легко выполнимые уроки.
- Переменное вознаграждение: предоставляет очки опыта и достижения за серии успехов.
- Инвестиция: отслеживает прогресс и адаптирует пути обучения на основе результатов пользователя.
Я сам пользуюсь duolingo и у меня нерпрерывный streak сейчас в 2 года

2) TikTok стал крайне привлекательным, используя модель hooked:
- Триггер: внешние триггеры включают видео, которыми делятся друзья, в то время как внутренние триггеры обращаются к желанию развлечься.
- Действие: предлагает простой процесс создания аккаунта и легкий просмотр видео.
- Переменное вознаграждение: представляет постоянный поток разнообразных, персонализированных коротких видео.
- Инвестиция: позволяет пользователям создавать и делиться своими собственными видео, увеличивая привязанность к платформе.

3) Slack стал популярной платформой для коммуникации на рабочем месте и она тоже применяет модель hooked:
- Триггер: использует как внешние, так и внутренние триггеры для привлечения внимания пользователей.
- Действие: предлагает удобный интерфейс для легкого обмена сообщениями и участия в каналах.
- Переменное вознаграждение: доставляет вознаграждения в виде положительной обратной связи и уведомлений о выполнении задач.
- Инвестиция: поощряет вклад пользователей через обсуждения и участие в проектах.
Мы использовали Slack до того, как перешли на наш мессенджер Time.

Но есть у модели и стандартные проблемы, которые могут уменьшать ее эффективность
1) Несоответствие потребностям пользователей - неспособность понять реальные проблемы пользователей или создание решений для несуществующих проблем.
2) Чрезмерное усложнение модели - слишком сложный UX или слишком много фичей могут оттолкнуть пользователей
3) Неэффективные системы вознаграждений - если вознаграждения слишком предсказуемы, то это плохо. Одновременно плохо, если они неконсистентны между собой и не поддерживают интерес и мотивацию пользователей.
4) Пренебрежение фазой инвестиций - слишком слабое или слишком сильное поощрение вклада пользователей в приложение приведет к тому, что они сорвутся с крючка
5) Этические проблемы - привычки должны приносить пользу клиентам иначе легко провалиться на темную сторону силы

#Management #ProductManagement #Econimics #PopularScience

Adaptive Enterprise Architecture: Towards a model (Рубрика #Architecture)

Недавно я решил почитать whitepapers по enterprise architecture и наткнулся на статью ученых из Морокко, где они пытаются скрестить ежа с ужом, а точнее корпоративную архитектуру со скрамом:) В начале статьи авторы отмечают, что текущие подходы к корпоративной архитектуре (TOGAF, Zachman) не обладают необходимой гибкостью для обработки быстрых, разноуровневых изменений, что характерны для модных ныне цифровых трансформаций. Они сосредоточены на реактивных процессах, ориентированных на заполнение кучи документов и с их помощью сложно управлять непредвиденными изменениями. Дальше авторы решают сформулировать набор критериев для адаптивной корпоративной архитектуры, куда входят такие вещи как
1) Support multi-level dynamics (поддержка многоуровневой динамики) - изменения бывают на разных уровнях и идут с разной скоростью, а значит архитектурный процесс должен уметь работать с каждым типом изменений. Авторы отмечают, что стандартный подход с архитектурой as-is и to-be уже не является статичным, а подвергается различным изменениям, что надо учитывать в архитектурных процессах
2) Sensing of change (ощущение изменений) - процесс должен поддерживать ощущение идущих вокруг изменений и позволять планировать свои инициативы для адаптации к изменениям
3) Process of adaptation (процесс адаптации под новые потребности) - это ключевая часть подхода авторов, что называется adaptive enterprise architecture
4) Complexity of change management (комплексность управления изменениями) - TOGAF и Zachman проваливают этот критерий, ребята хотят подход, который будет сильно проще с точки зрения управления изменениями
5) Handling of unforseen changes (обработка непредвиденных изменений) - это нужно для современных корпораций, что сталкиваются с высокими темпами непредвиденных изменений в своем бизнес окружении.
6) Explicit management of adaptability trade-offs - авторы отмечают важность явного управления компромиссами по адаптивности к изменениям. Сейчас это зачастую просто одно из нефункциональных требований или атрибутов качества решений, а в новом подходе им надо управлять явно
7) Evaluation of adaptation (эволюция адаптации) - для управления адаптацией ее надо уметь измерять, а занчит нам нужны метрики внутри процесса корпоративной архитектуры

Дальше авторы сравнивают по этим критериям разные подходы к корпоративной архитектуре и оказывается, что все они не удовлетворяют критериям. Они объединяют подходы в группы
1) Approaches based on guidelines (Zachman, TOGAF, Koffi A.D, LEAP, DYA)
2) Integration oriented approaches (Shmidt R & al, Zimmerman A & al)
3) Co-evolution oriented approaches (DEEVA, ACEM, ...)

И дальше авторы решают предложить свой подход, который удовлетворяет критериям и полагается на проверенные временем agile подходы, а точнее на Скрам. Дальше они рассказывают о том, какой Скрам замечательный, а потом натягивают его на архитектуру
1) У нас появляется роли architecture owner, business/IT owners. Первый отвечает за стратегический alignment, а вторые за оптимизацию бизнес-процессов и технического решения
2) Работа идет в циклах по 2-4 недели и используются скрам ритуалы: weekly cross-owner syncs, architecture reviews для обеспечения фидбека
3) Появляется архитектурный беклог, в котором приоритизируются изменения корп архитектуры, а также есть KPI и отслеживание движения As-Is / To-Be на графиках
Все остальные ритуалы agile про связь бизнеса и IT остаются на месте, просто EA беклог и ритуалы адаптивной корпоративной архитектуры живут рядом.

Для меня это whitepaper показался натягиванием совы на глобус без особых объяснений как это будет работать на практике, а не на бумаге:)

#Architecture #Software #Management #Governance #Engineering