Но даже если подписчик всего один, и сообщения доставляются последовательно, то и тогда очередность обработки сообщений может быть нарушена. Пример из NATS-Streaming Server:

📝 "With the redelivery feature, order can’t be guaranteed, since by definition server will resend messages that have not been acknowledged after a period of time. Suppose your consumer receives messages 1, 2 and 3, does not acknowledge 2. Then message 4 is produced, server sends this message to the consumer. The redelivery timer then kicks in and server will resend message 2. The consumer would see messages: 1, 2, 3, 4, 2, 5, etc...
In conclusion, the server does not offer this guarantee although it tries to redeliver messages first thing on startup. That being said, if the durable is stalled (number of outstanding messages >= MaxInflight), then the redelivery will also be stalled, and new messages will be allowed to be sent. When the consumer resumes acking messages, then it may receive redelivered and new messages interleaved (new messages will be in order though)."
- nats-streaming-server, issue #187 "Order of delivery", comment by Ivan Kozlovic
https://github.com/nats-io/nats-streaming-server/issues/187#issuecomment-257024506

#DDD #Microservices #DistributedSystems

Кстати, проблема очередности доставки сообщений хорошо описана в главе "Projections and Queries :: Building read models from events :: Subnoscriptions" книги "Hands-On Domain-Driven Design with .NET Core: Tackling complexity in the heart of software by putting DDD principles into practice" by Alexey Zimarev ( @zimareff )
https://www.amazon.com/Hands-Domain-Driven-Design-NET-ebook/dp/B07C5WSR9B

И он добавил несколько интересных аргументов в чат канала:
https://news.1rj.ru/str/emacsway_chat/85

P.S.: это один из тех людей, кому я искренне благодарен за влияние на мое профессиональное развитие.

#DDD #Microservices #DistributedSystems

Немного юмора в тему "Совершенного Кода":
https://github.com/kelseyhightower/nocode

#SoftwareDesign #CleanArchitecture

Уже старая, но невероятно полезная статья для тех, кто впервые работает на заказчика из США:
https://bulochnikov.livejournal.com/2326301.html

#Career

Если вдруг кто пропустил эту новость - вышло второе издание бестселлера "The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition" (2nd Edition) by David Thomas: https://www.amazon.com/Pragmatic-Programmer-journey-mastery-Anniversary/dp/0135957052/

Автор - один из 17 подписантов Agile-manifesto и его соавтор.

Кстати, Dave тоже ударился в функциональное программирование, и написал книгу "Programming Elixir".

А так же он был редактором книги Джо Армстронга по Эрлангу:
"Dave Thomas edited my Erlang book"
https://web.archive.org/web/20170830231254/http://joearms.github.io/2013/05/31/a-week-with-elixir.html

#Agile #Career #FunctionalProgramming

📝 "A good architecture is characterized by crisp abstractions, a good separation of concerns, a clear distribution of responsibilities, and simplicity.
All else is details."
- Grady Booch. Позавчера.
https://twitter.com/Grady_Booch/status/1301810362119905285?s=19

[UPDATED]: Там весь тред заслуживает на прочтение.

#SoftwareDesign #SoftwareArchitecture

В том же треде:

📝 "All architecture is design, but not all design is architecture.
Architecture represents the set of significant design decisions that shape the form and the function of a system, where significant is measured by cost of change."
- Grady Booch
https://twitter.com/Grady_Booch/status/1301810380675588096?s=19

#SoftwareDesign #SoftwareArchitecture

Там же:

📝 "You cannot reduce the complexity of a software-intensive systems; the best you can do is manage it."
- Grady Booch
https://twitter.com/Grady_Booch/status/1301810363734736896?s=19

#SoftwareDesign #SoftwareArchitecture

Гы... недавно был холиварчик в архитекторской группе на эту тему. Там же:

📝 "A software architect who does not code is like a cook who does not eat."
- Grady Booch
https://twitter.com/Grady_Booch/status/1301810374598033408?s=19

#SoftwareDesign #SftwareArchitecture

📝 "An honest estimate is not a date. It is always a range of dates with probabilities assigned to the range."
- Robert C. Martin
https://twitter.com/unclebobmartin/status/1302600840138485760?s=19

#Agile

Знаете этого парня, да?
- https://leanpub.com/u/johnbywater
А его книгу?
- https://leanpub.com/dddwithpython

#DDD #DistributedSystems #EIP #EDA #Microservices

Две превосходные статьи о том, как устроено сжатие данных в time-series расширении TimescaleDB для PostreSQL.

- https://blog.timescale.com/blog/time-series-compression-algorithms-explained/
- https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/

#Database #PosgreSQL #HighLoad #Scaling

Интересное видео от сообщества @drypython

#FunctionalProgramming

Немного дискуссионный, но весьма интересный материал от Vladimir Khorikov ( @vkhorikov ) на один из самых частых вопросов в DDD - может ли один агрегат иметь ассоциацию по ссылке с другим агрегатом?

"Link to an aggregate: reference or Id?"
https://enterprisecraftsmanship.com/posts/link-to-an-aggregate-reference-or-id/

#DDD #Microservices

Знатный холиварчик титанов получился на тему FP vs OOP. Не без интересных исторических подробностей.
https://twitter.com/Grady_Booch/status/1302678071049216000?s=19

#FunctionalProgramming #OOP

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

Пути решения проблемы здесь есть два:

1. Обретать знания. Страх - всегда от незнания.
2. Воспитывать в себе храбрость. Это может показаться неуместным, но именно об этом говорит Кент Бек:

#Agile #Career

📝 "Храбрость

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

Я расскажу вам о том, как храбрость срабатывает в реальной жизни. В середине восьмой итерации включающего в себя 10 итераций рабочего графика (25 из 30 недель) первой версии первого крупного ХР-проекта команда обнаружила фундаментальную ошибку в архитектуре системы.

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

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

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

Еще один смелый ход — отказ от ранее разработанного кода. Представьте, что в течение всего рабочего дня вы работаете над реализацией некоторой функциональности. Работа идет неплохо, но когда вы близки к ее завершению, компьютер зависает. На следующее утро вы приходите на работу и в течение получаса восстанавливаете то, над чем работали весь предыдущий день, однако на этот раз код получается более чистым и более простым. Используйте это. Если приближается конец рабочего дня и код все еще не поддается контролю, выбросьте его. Может быть, следует сохранить тестовые случаи, если вам понравился разработанный вами интерфейс. Однако это не обязательно. Возможно, следующим утром будет легче начать с нуля.

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

Стратегия проектирования в ХР напоминает алгоритм взбирания на холм (hill climbing). Вы делаете простой дизайн, затем вы делаете его более сложным, далее вы его упрощаете, потом опять усложняете. Проблема подобных алгоритмов состоит в том, что вы ищете локальный оптимум, — при этом никакое незначительное изменение не может улучшить ситуацию, однако улучшения можно достичь, используя значительное изменение.

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

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

Коммуникация идет на пользу храбрости, так как благодаря коммуникации вы обретаете возможность для осуществления более рискованных и более заманчивых экспериментов. «Тебе это не нравится? Я просто ненавижу этот код! Давай вместе посмотрим, в какой мере мы сможем переделать его сегодня днем». Простота идет на пользу храбрости, так как, обладая более простой системой, вы сможете позволить себе более смелые действия в ее отношении. Маловероятно, что вы нарушите ее функционирование по неизвестным причинам. Храбрость способствует простоте, ведь как только вы видите способ упростить систему, вы немедленно пробуете его реализовать. Надежная обратная связь идет на пользу храбрости, так как в процессе серьезной модернизации кода вы чувствуете себя значительно увереннее, если вы можете щелкнуть на кнопке и увидеть, что в результате тестирования все тесты показывают зеленый цвет. Если зеленым цветом окрашиваются не все тесты, вы переделываете или просто выкидываете свой код."

- "Extreme Programming Explained" 1st edition by Kent Beck

#Agile #Career