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

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

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

An Introduction to Residuality Theory - Barry O'Reilly - NDC Oslo 2023 (Рубрика #Architecture)

Интересное выступление про residuality theory от Barry O'Reilly, автора теории. Автор делает подход к созданию теории, что поможет инженерам прокачиваться в архитектуру не просто набивая опыт, а используя достижения complexity theory, но без погружения во всю ее сложность. Для этого автор начинает с определения упорядоченных и неупорядоченных систем, а дальше он показывает как стрессоры (неизвестные факторы) могут негативно влиять на архитектуру. С учетом вариативности окружающего мира проанализировать все состояния системы и влияние стрессоров на систему в этом состоянии не представляется возможным. Поэтому автор предлагает рассматривать систему не целиком, а изучать то, что остается от системы, если случается пи... (стрессор X). Эти остатки определяют будущее системы и могут быть использованы для управления архитектурой программного обеспечения. Для моделирования стрессоров нам поможет метод Монте-Карло с его рандомизацией, которую мы можем применить к возможным стрессорам.

Дальше автор вводит рассказывает про аттракторы как устойчивые состояния, в которые скатывается система. Он приходит к ним через NK модель Кауффмана. У нас есть система с N элементами, принимающими значение 0 или 1, параметром K характеризующим связность (например, максимум связей одного элемента). Суть в том, чтобы показать, что при росте N и K у нас в системе увеличивается количество аттракторов. Заодно там появляется вероятностная характеристика P, которая характеризует bias связей между элементами. Финалом размышлений становится вывод некоторой выпуклой кривой критичности, которая вырисовывается в пространстве N и K, где мы играем с количеством элементов и связей между ними (еще один способ определить количество сервисов и связей между ними).

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

Дальше автор приводит крутые примеры из дизайна системы для управления зарядными станциями для электромобилей. Ребята учли corner cases, которые бывают с зарядкой электромобилей и это помогло потом упростить решение проблем с людьми, что оставляют заряжать машины на целый день, а также с ребятами, что занимались саботажем. А вообще история прикольная и рекомендую посмотреть ее в оригинале.

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

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

В общем, все звучит достаточно логично и напоминает мне подход генеративно-состязательных сетей, но только к архитектуре. Дальше я планирую прочитать whitepaper "Residuality Theory, random simulation, and attractor networks" от автора доклада и рассказать про него:)

#DistributedSystems #SystemDesign #Math #Engineering #Architecture #SoftwareArchitecture #ComplexityTheory #Software #Processes

Написал свой первый пост в телетайп, потому что превысил ограничение на количество символов

https://teletype.in/@vdprud/book-building-event-driven-microservices

Даже в пхп есть неймспейсы

И доклад хороший, и пример хороший организации, привлечения для научной группы

📖 Presentation:
👨‍🔬 Кирилл Хоружий "Введение в методы поиска короткого пути на больших графах"
📹 Video: https://youtu.be/2J3eGGH-uiM?si=9xgHtcCpBj0wKXC0
✔️ Abstract: https://t.iss.one/sberlogabig/451

Не то что наш админ работяга с завода

Дурку для стартступеров подвезли

🏎️ FastHTML = FastAPI + HTMX 💨

Фронт на питоне.

Я ждал, я надеялся.

🔗 Лендос: fastht.ml
🔗 Github: github.com/AnswerDotAI/fasthtml
🔗 Комменты на HN: news.ycombinator.com/item?id=41104305

Мнения?

Отличный доклад с PiterPy 2020 про системы типов. Очень понятное введение в теорию с примерами.

Стоит смотреть хотя бы ради этого момента на видео

То чувство, когда думал, что Rust — про безопасный C++, а оказалось — про быстрый Haskell

12 строчек разделяют гибкость от безопасности и производительности. Разумная цена?

Подборка статей Филиппа Вадлера по аффинным типам

Однозначно в вишлист

Сурцы

Наткнулся на очень хорошую обзорную статью Rust vs. Haskell, благодаря которой поближе познакомился с Haskell. В целом мое первое впечатление от Rust как высокопроизводительном варианте функциональном языке ака Haskell оказался правдивым. Но Rust за свою эффективность заплатил отказом от части фич ML семейства:

Partial field accessors

Благодаря этой возможности в Haskell в конструктор типа-суммы можно передавать аргументы одного из типов, например:

data Croissant  = Plain {price :: Double}
  | WithFilling {filling :: String, price :: Double}

let plain = Plain 1.75

-- This is ok and works as expected:
print $ price plain
-- Prints: 1.75

Runtime and concurrency

Rust пошел по пути stackless корутин со всеми любимыми async/await, что нельзя сказать про Haskell с более приятным синтаксисом:

concurrentProgram :: Work -> IO Result
concurrentProgram work = do
  results <-
    timeout twoSeconds $
      mapConcurrently (doWork work) [ServiceA, ServiceB, ServiceC]
  pure $ case results of
    Just success -> Success success
    Nothing -> Timeout
 where
  twoSeconds = 1000 * 1000

-- Run the program
concurrentProgram someWork

Generators

В Rust толком нет ленивых вычислений, которые могут быть очень полезны для оптимизации памяти. Haskell напротив всегда лениво вычисляется.

Higher-order programming

В Haskell все построено на высоко-уровненных абстракциях как монады, функторы и т.д., которые делают язык более выразительным. Но с другой стороны, это все не бесплатно, а Rust предоставляют достаточную выразительность также

Добрался до новинки от Влада Хононова

Буду тут оставлять отрывки, под тегом #balancing_coupling

#balancing_coupling

Дедушки вспоминают пришествие микросервсивов:

Around 2014, yet another “decoupling salvation” came around — microservices. I even remember a slide saying “microservices is the architecture for decoupling” at some conference