https://why-upgrade.depesz.com/show?from=11.13&to=13&keywords=

Просто шикарный сервис для понимания нафига обновляться на свежий постгрес и что обновление даст

https://s0er.ru/codelabs/arch_stream_18/#0
Saga и ее рализации

== Индексы. вводная
https://telegra.ph/Pss-paren-indeks-nuzhen-05-05

SAGA - подборка ссылок из обсуждений чата канала:

🔷 Первоисточник по SAGA: "SAGAS" by Hector Garcia-Molina, Kenneth Salem

🔷 Перевод первоисточника по SAGA: "Гектор Гарсия-Молина и Кеннет Салем — «Саги»" / Михаил Ланкин

🔷 Applying the Saga Pattern • Caitie McCaffrey • GOTO 2015

🔷 Saga distributed transactions pattern

🔷 Process Manager Pattern

🔷 Compensating Transaction pattern

🔷 Пример реализации SAGA на Enterprise Integration Patterns (source code)

🔷 Пример реализации Process Manager от сообщества Microsoft (комментарий Greg Young). Альтернативы и обоснование.

🔷 Patterns and implementations for a banking cloud transformation

🔷 Несколько реализаций саг:
- https://axoniq.io
- https://eventuate.io/abouteventuatetram.html
- https://github.com/eclipse/microprofile-lra
- https://github.com/jbosstm/narayana/tree/master/rts/lra

🔷 Awesome workflow engines

🔷 "A long-running transaction model of workflow" by Quanzhou Hu; Jia Liu; Yi Zhuang; Yi Liu

🔷 "The CORBA Activity Service Framework for supporting extended transactions" by Iain Houston, M. C. Little, Ian Robinson, Santosh K. Shrivastava, Stuart M. Wheater

🔷 "What are long running processes?" by Bernd Rücker

🔷 Чем отличается SAGA от Process Manager:
- https://event-driven.io/en/saga_process_manager_distributed_transactions/

- https://stackoverflow.com/a/33652837

- https://blog.devarchive.net/2015/11/saga-vs-process-manager.html?m=1

🔷 "Eventually consistent" by Werner Vogels

🔷 "ACID properties of transactions"

🔷 "Atomicity :: Chapter 12. Berkeley DB Transactional Data Store Applications"

🔷 "Atomic - indivisible, not capable of being cut/divided into smaller pieces"

🔷 "Consistency Models"

🔷 интервью "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts, в котором V.Vernon предлагает использовать Process Manager Pattern для обработки процессов, охватывающих несколько агрегатов в условиях Eventual Consistency.

Посмотреть реализацию в исполнении V. Vernon, включая ProcessTimedOut (о чем часто спрашивают), можно здесь:
- Java
- .Net

🔷 "Camunda Platform 8 Docs :: BPMN coverage"

🔷 Eclipse Microprofile стандарт имеет понятие LRA - Long Running Application. это есть их интерпретация саг

🔷 Microprofile-compatible фреймворки а-ля micronaut.io

🔷 RedHat развивает референс имплементацию Microprofile в виде своего фреймворка quarkus.io

🔷 Red Hut Summit "Saga: The new era of transactions in a
microservices architecture" by Giovanni Marigi, Mauro Vocale. BOSTON, MA | MAY 7-9, 2019

🔷 Вот пример Camunda. их интерпретация и имплементация саг )). Там всё очень упрощено и декларативно.

🔷 Architecture standard определяет сагу в пункте 21.2.7. Ensuring Global Consistency with Saga Patterns

Спасибо, что развиваете отрасль с помощью нашего чата!

#DistributedSystems #Многоликий

Штука вместо кронтаба
https://rocketry.readthedocs.io/en/stable/index.html

Не корреляцией единой. Доказательства причиноследстыенной связи на пайтн
https://nuancesprog.ru/p/16095/

PGCat PgBouncer rewritten in Rust, with sharding, load balancing and failover support.

https://github.com/levkk/pgcat

PS: thanks @nosingularity for the link

#postgresql #postgres #sql #rust

Testing on the Toilet

До года так 2005 в Google не было принято писать тесты. Компания переживала бурный рост, а хоть туда уже приходили лучшие инженеры, на тесты как-то время не хватало. Некоторые из разработчиков были недовольны таким положением вещей, и родилась какая-то абсолютно гениальная идея, с которой все единогласно согласились, и надо было лишь правильно ее исполнить.

Testing on the Toilet (TotT) -- одностраничные листовки, расклеенные в туалетных кабинках офисов Google и дающие разработчикам советы о том, как лучше тестировать их код, -- это наш, можно сказать, институт, на котором держится Google. Они упоминались в Washington Post, New York Times и единогласно были высмеяны и признаны воплощением культуры Гугла.

Как и почти все вещи в Google, TotT возник в результате попытки решить одну конкретную проблему. Код стало невозможно писать из-за слишком большого количества багов. В середине 2005 года была создана группа Unittest, чтобы обучать разработчиков, как тестировать свой код. В то время написание тестов не было прям уж нормой в Google. Члены группы начали писать Codelabs (лабораторные пошаговые работы), организовывать Fixit weeks (когда все в команде чинят flaky тесты) и проводить еженедельные лекции для Noogler (New Googler) о том, как важно писать тесты.

Как я бы сказал по-английски: "This trained the Nooglers". А что делать с теми, кого уже наняли? Во время митинга в конце марта 2006 г. один из директоров предложил идею о расклеивании листовок в публичных местах. А куда все ходят точно хотя бы раз в день? Столовые и туалеты. Кафе не были хорошим решением, так как фокус всегда был смещен на еду и общение. Остаются уборные. Что ж. Кто-то посмеялся, но никто не задал вопроса, а нужно ли это делать. В итоге это вошло в OKR, и листовки стали появляться во всех туалетах офисов Google.

Один из инженеров написал первый эпизод: "Better stubbing in Python". Его наклеили везде в офисах Долины и Лондона. Кто-то подхватил и рассказал об этом всем сокомандникам, пошло сарафанное радио. Это было необычно, и все согласились, что это может решить их проблему. TotT распространялся с немыслимой быстротой.

Ana Ulin стала лидером этой программы, когда она добровольна взяла ответственность за вычитку и качество материала. Так идея была подхвачена, на неё нашлись правильные и нужные люди. Это ещё одна часть культуры Google -- если ты что-то делаешь и делаешь это хорошо, ты теперь за это ответственен. Те, кто обожал тестирование, писали свои методы как писать правильные тесты на С++, как работать с Unicode. Абсолютно все офисы стали подхватывать это, и даже в планировки новой постройки стали рисовать места, где будут наклеивать эти листовки.

Со временем многие авторы начали писать свой контент (в том числе появились разделения на Tips of the Week, которые появлялись в блогах), и люди прислушивались к советам. Начались обсуждения, бесконечные дебаты, появились арбитры, но самое главное -- были сообщения о положительных результатах, что теперь кто-то научился правильно писать на Python или смог обойти баг с памятью в C++. Рекламировались и внедрялись новые инструменты и методы. Качество, скейл рос. Люди стали цитировать в код ревью эпизоды, люди доверяли этому источнику. Пусть решения не были идеальными, но все смогли о чём-то договориться.

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

Несмотря на все изменения, уже сколько раз поменявшихся лидеров программы, TotT уже 17 лет выпускает эпизоды. Появились отдельный культы и программы, которые пишутся для всех технологий. К сожалению, всё не повесишь в туалетах, а некоторые стали невозможными для публичных глаз :)

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

Больше и первые эпизоды здесь:
https://mike-bland.com/2011/10/25/testing-on-the-toilet.html

Паттерны хранения деревьев в БД
https://habr.com/ru/company/bimeister/blog/672634/
• Adjacency List;
• Nested Sets;
• Closure Table;
• Materialized Path.