131–140 of 313 posts
Earlier quoted context omitted.
Your desk runs a web server? I need to step up my game...
Yeah, it's a sit/stand Linak desk. I hooked up an ESP32, 2 channel relay (up/down control), and distance sensor (to detect height). Pushes height to graphite and position is settable remotely. :)
Earlier quoted context omitted.
Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.
The majority of people who clicked on the link did it on purpose, so a better pattern would be to make it unsubscribe immediately with a "didn't meant to unsubscribe? click here to undo" link afterwards.
A single step, a button push, to confirm an unsubscription is fine.
Earlier quoted context omitted.
This still seems like really bad idea when the POST request is right there. Serve a page with a button saying "are you sure"?
Do you really like having to confirm every action? For interfaces that you use all the time, it's nice to be able to eliminate extra steps.
Earlier quoted context omitted.
Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.
Confirmation steps should only be used if the action can't be easily undone.
Hello! Long-time lurker, and guilty dev behind the garage door. You can see the (broken) code I wrote here: https://github.com/wpearse/wemos-d1-garage-door-wifi I'll get around to fixing it later this week. Also, an apology: I should have used "side-effect-free" instead of "idempotent" in my tweets.
> I should have used "side-effect-free" instead of "idempotent" in my tweets The HTTP term is "safe method". Although you weren't even wrong because section 4.2.2 of RFC7231 (i.e. HTTP) defines all safe methods, including GET, as idempotent. I think they use this language because nothing is truly side-effect free. In fact GETs can have side-effects, the most obvious of which is writing the fact of it to a logfile, an…
However, an idempotent HTTP call is certainly not a pure function which some people seem to be mixing up. Pure functions don't work with I/O.
REST is bit more specific and explicitly requires GET to be nullipotent which really means "effect free" - it just reads and doesn't alter the state on the remote system at all.
Side-effects like log files, rate-limiting, etc. will always exist, but they do belong to a different 'layer', so to speak. That is, these should be unobservable side-effects (also think about minuscule effects on the power grid, the fact that a request might write something to an ARP-cache, etc. - they all happen at different layers, so the quantum world state keeps changing, but that's not what this is about). Whether an X-Request-Count header violates the requirements or not depends on interpretation. From the garage door perspective, I wouldn't care...
When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…
If the unsubscribe link were unique for each subscriber would the law still be satisfied?
Earlier quoted context omitted.
“Toggle” is by definition not idempodent, because you get a different result each and every time. “Open” and “close” are idempodent, but not safe. The result of a GET request should always be idempodent and safe.
GET requests should have no side effects. In other words NOOP is idempotent
When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…
If the unsubscribe link were unique for each subscriber would the law still be satisfied?
This doesn't seem very likely, so I guess that a whole load of unique unsubscribe links got dumped into slack which started following them.
Earlier quoted context omitted.
What would the problem be in just showing a button that says "Confirm unsubscribe" that sends a POST request? A lot of sites does something like that for their newsletter unsubscription.
I like the one-click URLs though. It irritates me to no end to click unsub, then wait for a page to load then repeat my intention.