nulagrithom

Do the chat/call/video call functions rely on Slack or Hangouts? Can it be done standalone?

You wouldn't put a card number in the path anyway (for obvious reasons). Far more sensible to put that in the request body.

And who's to say you can't put the reason in the body and still keep the code? What are you hurting by sending back 400? Unless you have lb's taking out nodes because of excessive 4xx's (which sounds like insanity) I don't see a reason _not_ to send 4xx's. At the very least it's a useful heuristic tool.

Agreed. What else would you use 400 for? I don't see how sending back 400 is going to hurt.

The payoff of using 400 is you can watch your 400 rates with almost no effort (HTTP is well established and there's many many tools out there.) If you somehow start accidentally munging the card number sometimes or if your card processor starts doing wacky stuff you'll see a spike in 400 rates.

If it was really that troubling that declined cards are expected, I would personally at least want to see 200 come from the internal API and 400 go out to the client.

And if your "intermediate devices" start doing goofy stuff to 400's then you've got bigger problems... 4xx's shouldn't be taking nodes out of prod. That's wack.

It's short for set configuration.

Maybe that just escaped you from some reason, but I would think it's perfectly understandable for just about anyone.

Curious if anyone else here had a hard time parsing it...

At one point the planet was nothing but a hot 230 °C ball. How much pedantry do you want to get in to?

"Ever" vs "human history" almost seems like a nitpick. _We_ have never seen it this hot, ever.

While we're hijacked...

Is F# still the red-headed step-child of Core?

Last I fiddled with it F# was looking pretty unloved, but to be fair C# was still having a hard time with Core itself.

I don't understand this one:

> If I wait exactly one second, Unix time advances by exactly one second

How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds.

I feel like this is wrong too:

> If there’s a leap second in a day, Unix time either repeats or omits a second as appropriate to make them match.

It's not Unix time doing that. It's UTC.

For one, it's single threaded (last I checked). It also seems to be built on a big heap of messy Java.

Check out Cuberite for comparison. It's a Minecraft server built from the ground up in C++ and it's waaaaaaaay faster than the official server. Advantages of a rewrite I suppose...

We're increasingly incapable of surviving on a planet that's perfectly suited to us.

There's no chance we "look towards the stars" if we can't fix the ground.

> Users absolutely hated the new system.

I feel like this is a universal absolute, doubly so when it comes to enterprise apps (the lone exception being when we switched from Lotus Notes to Gmail -- then only half the company hated the change).

I would've liked to know how long the changes were in place and how it affected productivity metrics, especially the amount of training time spent on new users. As is, the article seems kind of obvious. Enterprise users abhor change; who knew?

> Just like you wouldn’t appreciate a dictionary with only 10 words per page (so many pages to flip through!)

This also makes me question the veracity of the article. It's a really terrible metaphor that makes me wonder if they were _solely_ concerned with pretty design on the outset.

I want a dictionary that shows me 1 word per page, with a search bar. The page flipping functionality is useless and can be removed entirely. It's a bad workflow.

I can definitely say that over the past 20 years, our in-house LoB app has developed some really bad workflows as well (business changes a lot over 20 years). Removing these bad workflows would give us back a ton of screen real estate without losing productivity.

The causality is backwards. I don't want to create whitespace by changing the design and ruining the functionality. I want to change the functionality which will create more whitespace and allow room for beautiful design.

DocuSign should've recognized this and let them know the flaws in their plan, but in my experience they're _way_ too sales-oriented to ever do this.

I had a similar experience. I explored their API and got stuck on how to implement my use-case and how to ensure it's legally binding. Sales and "technical" resources assured me it was possible, didn't explain how, and everyone balked at any sort of legal questions and basically told me that was all on us to sort out.

I decided I didn't need help creating a box for users to scribble on. E-signature isn't a technical challenge at all.

Yes, yayana explained my error pretty succinctly before you did...

Yup! You're right.