51–60 of 69 posts
The diagram in the article shows “Header Idempotency Key : "A"” (honestly not sure whether the second, third and fourth of those spaces exist: the diagram’s text kerning is atrocious). This should be the header field `Idempotency-Key: "A"`, though “A” would be a bad string to use (see Security Considerations).
My day-job is Data Engineering. We've carefully built our ETL patterns/tools/data structures to be idempotent. It's amazing how freeing this is. Dealing with cascading failures, intermittent failures, delays, re-runs and time-zones are all os much more manageable when we know that just re-running any given task will do the right thing. It's also amazing how hard of a concept idempotent data pipelines are for some fol…
I try to make my pipelines idempotent, but a couple of them require us to send the output file to someone's email. Does anyone know how to send an email idempotently?
You can embed tracking in your email to see if it's been opened, and not resend in that case, but this will be flakey as it's easy to disable email trackers.
Earlier quoted context omitted.
I’m not totally sure, but in math “idempotent” elements are those for which x^2 = x. And so in software engineering it refers to operations for which doing them twice has the same effect as doing them once. Maybe this is what is meant by “same power”?
i could agree with you. my pet peeve is that the name of the phenomenon where repeated executions result in same result (where same even includes unique identifier) shouldn't be idempotency . especially in computing where, in my experience, any attempt to implement it involves some logic which checks to see if we've already observed the desired effect of the action.
Idempotency is one mathematical concept that's pretty useful for software engineers to understand. Heck, might be more useful than BigO. - Useful to know when you work with APIs (as the article outlines). - Very useful when working with background jobs. You're not gonna have a good time if those aren't idempotent. - Good to know for interviews. I was asked to explain idempotency a handful of times, weird as that is.
* In the object-oriented sense, `obj.f(args...)` does not mutate `obj` after the first time.
* For pure unary functions, `f∘f === f` - that is, repeated application does not change the result, e.g. `abs(abs(x)) === abs(x)`
* For pure binary functions, `f(x, x) === x`. I'm not sure how useful this is but it seems to be used in math.
* For pure binary functions, `f(x, a) === x` and/or `f(a, x) === x`. These would probably be individually called left-idempotent and right-idempotent in some order, along with two-sided idempotent for the combination (akin to left identity (related!), left inverse, etc.); notably these are more general than (and all imply) the above. This could be extended to further arities; usually the preserved element will be either first or last in sane functions. "and not" works in one direction; many functions like "bitwise and", "bitwise or", "min", and "max" work in both directions.
One of the things I think I did right in my career is working on payment and billing systems early on. It does teach you how to build at least semi-reliable software because people tend to get really mad when you screw with their money. It also is a good introduction to regulation and compliance. Idempotency was is one of the concepts you get taught on day one in that field (as kind of demonstrated by that being the…
Interestingly, I didn’t have to be taught about idempotency early on in my career; I’m pretty sure I didn’t even know what that word meant. I’m a naturally curious person and I was always curious about the failure cases for the software I worked on—e.g., “What happens if this request is successful but times out before returning a response to the client?” I honestly assumed every programmer asked these types of questi…
Fancy word for an obvious concept.
You say it like it's something bad. Having a common vocabulary is extremely helpful for communication. Instead of restating the obvious concept over and over all the time you can just ask your peer "is this idempotent?". Naming something also helps us to think about it. "A square" is also an obvious concept, but by naming it you can reason about it more easily, and use it to define more abstract concepts later. One o…
The software industry is littered with these words. Design patterns especially. Rob Pike once referred to it as infatuation with nomenclature.
Idempotency is one mathematical concept that's pretty useful for software engineers to understand. Heck, might be more useful than BigO. - Useful to know when you work with APIs (as the article outlines). - Very useful when working with background jobs. You're not gonna have a good time if those aren't idempotent. - Good to know for interviews. I was asked to explain idempotency a handful of times, weird as that is.
One irritating thing is that there are at least 4 different senses of "idempotent" in the wild: * In the object-oriented sense, `obj.f(args...)` does not mutate `obj` after the first time. * For pure unary functions, `f∘f === f` - that is, repeated application does not change the result, e.g. `abs(abs(x)) === abs(x)` * For pure binary functions, `f(x, x) === x`. I'm not sure how useful this is but it seems to be used…
Earlier quoted context omitted.
I want to meet the article that isn’t safe to read even if you’re familiar with its content.
Well, it's conceivable that you could end up creating a separate copy of the information in your brain's neural network. Now imagine you keep getting interrupted in the middle, but really want to read it all, thus gradually filling the whole of your brain capacity.