А
Ребята, привет
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
Несколько хватит?:)
Size: a a a
2020 April 26
JM
Не известно :)
DS
Ребята, привет
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
Зачем? Берите задачу с ролью SolA. Зачем Вам чужие ожидания? Формируйте свои, а мы поможем.
E
Ребята, привет
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
У @mxsmirnov целый тренинг в мае
MS
Ребята, привет
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
Я хотела бы взять несколько уроков у солюшн архитектора
Посоветуйте кого-нибудь, пожалуйста
Привет! А есть какие-либо предпочтения по предметной области?
M
@mxsmirnov добрый день! А где найти анонс майского тренинга? Заинтересовало)
MS
@mxsmirnov добрый день! А где найти анонс майского тренинга? Заинтересовало)
Добрый день! https://www.itexpert.ru/aws-online/ Не стесняйтесь задавать вопросы
M
Добрый день! https://www.itexpert.ru/aws-online/ Не стесняйтесь задавать вопросы
Спасибо! Ознакомилась) формат офлайн?
MS
Спасибо! Ознакомилась) формат офлайн?
Нет. В конце мая будет онлайн. Исходный, оффлайновый курс, 3-х дневный и мы надеемся сделать следующий поток в июне https://www.itexpert.ru/aws/
M
Супер) спасибо за ответы
2020 April 27
PD
Коллеги, а есть умное название для условия "не строгой идемпотентности" - того, что нужно для распределенных систем.
Например, createObject использовать нельзя, так как при его повторе будет сделана копия.
Но если разнести createObject на два метода: generateId и createObject(id), то каждый из них по отдельности уже можно безопасно повторять.
Но generateId - не идемпотентен, хотя и безопасен. Есть ли правильное слово для подобных требований к методам?
Например, createObject использовать нельзя, так как при его повторе будет сделана копия.
Но если разнести createObject на два метода: generateId и createObject(id), то каждый из них по отдельности уже можно безопасно повторять.
Но generateId - не идемпотентен, хотя и безопасен. Есть ли правильное слово для подобных требований к методам?
GK
Коллеги, а есть умное название для условия "не строгой идемпотентности" - того, что нужно для распределенных систем.
Например, createObject использовать нельзя, так как при его повторе будет сделана копия.
Но если разнести createObject на два метода: generateId и createObject(id), то каждый из них по отдельности уже можно безопасно повторять.
Но generateId - не идемпотентен, хотя и безопасен. Есть ли правильное слово для подобных требований к методам?
Например, createObject использовать нельзя, так как при его повторе будет сделана копия.
Но если разнести createObject на два метода: generateId и createObject(id), то каждый из них по отдельности уже можно безопасно повторять.
Но generateId - не идемпотентен, хотя и безопасен. Есть ли правильное слово для подобных требований к методам?
Опиши пожалуйста более подробно кейсы. Очень интересно
Термина такого не встречал, но можно наверно квази, псевдо
Термина такого не встречал, но можно наверно квази, псевдо
PD
Ну, если у тебя какая-то многосервисная архитектура, то всегда есть проблемы с сетью и т.п. И поэтому на все вызовы вешается какой-то retry для их повтора. Есть популярные слова, что повторять безопасно можно только идемпотентные методы.
Это верно, но в реальной жизни есть неидемпотентные методы, которые можно безопасно повторять - всякие генераторы ключей и т.п.
Тогда нарушается идемпотентность суммы методов, но это не очень страшно и не всегда вообще достижимо.
Это верно, но в реальной жизни есть неидемпотентные методы, которые можно безопасно повторять - всякие генераторы ключей и т.п.
Тогда нарушается идемпотентность суммы методов, но это не очень страшно и не всегда вообще достижимо.
GK
Ну, если у тебя какая-то многосервисная архитектура, то всегда есть проблемы с сетью и т.п. И поэтому на все вызовы вешается какой-то retry для их повтора. Есть популярные слова, что повторять безопасно можно только идемпотентные методы.
Это верно, но в реальной жизни есть неидемпотентные методы, которые можно безопасно повторять - всякие генераторы ключей и т.п.
Тогда нарушается идемпотентность суммы методов, но это не очень страшно и не всегда вообще достижимо.
Это верно, но в реальной жизни есть неидемпотентные методы, которые можно безопасно повторять - всякие генераторы ключей и т.п.
Тогда нарушается идемпотентность суммы методов, но это не очень страшно и не всегда вообще достижимо.
Квазиидемпотентность
PD
Ну, вот квази мне совсем не нравится )
И как бы формально определить данное свойство )
И как бы формально определить данное свойство )
e
гуглежка подсказывает partial idempotency
GK
Ну, вот квази мне совсем не нравится )
И как бы формально определить данное свойство )
И как бы формально определить данное свойство )
Ну квази же фактически) Не встречался, кстати, с такой постановкой)
Если получится формально определить, будет доклад
Если получится формально определить, будет доклад
GK
гуглежка подсказывает partial idempotency
Мне кажется, это не совсем то, о чём Фил говорит. Partial - это когда часть объекта (одного) меняется
DK
Коллеги, а есть умное название для условия "не строгой идемпотентности" - того, что нужно для распределенных систем.
Например, createObject использовать нельзя, так как при его повторе будет сделана копия.
Но если разнести createObject на два метода: generateId и createObject(id), то каждый из них по отдельности уже можно безопасно повторять.
Но generateId - не идемпотентен, хотя и безопасен. Есть ли правильное слово для подобных требований к методам?
Например, createObject использовать нельзя, так как при его повторе будет сделана копия.
Но если разнести createObject на два метода: generateId и createObject(id), то каждый из них по отдельности уже можно безопасно повторять.
Но generateId - не идемпотентен, хотя и безопасен. Есть ли правильное слово для подобных требований к методам?
мне кажется, что если возникает кейс "не идемпотентен, хотя и безопасен", то уже следует использовать слово, отличное от идемпотентности. Потому что получается ,что тебе нужно выделить свойство, которое соответствует множеству, которое содержит внутри идемпотентные методы.
A
безопасное отсутствие идемпотентности