Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Order of the JSON

blog.almaer.com

Post reply on HN
Print view View original

91–100 of 126 posts

Re: The Order of the JSON

#91

Post by dec0dedab0de »

Ididntdothis wrote: post #5

This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

I think stuff likes this is the real price of not hiring really good people.

I think stuff like this is why decent developers don't become "really good" when working in these environments. If you have a culture of letting people figure things out, and forgiving mistakes, then you'll end up with better engineers. On the other hand if you have a culture of protecting "territory", and blame then you'll get 6 months for 9 people to check a box.

Re: The Order of the JSON

#92

Post by inopinatus »

jwilliams wrote: post #46

(I've used both DataPower and COBOL - I've got a healthy respect for robust, long-lived legacy systems). I must admit I was scratching my head on this. The JSON spec might not specify order, but the serialized JSON is ordered by nature. JWT needs it for example (and I'd assume many signature models). Or you might have a caching layer that needs it. Maybe unchecking this causes the legacy backend to get hammered? Ther…

> JWT needs it

I already had at least four solid reasons not to use JWT. Still, adding another just keeps the dumpster fire burning.

By which I mean, in the most oblique and backhanded fashion, that there’s not going to be any reason for validating JSON order that doesn’t ultimately reveal or confirm a design gaffe somewhere down the rabbit hole.

Re: The Order of the JSON

#93

Post by cat199 »

jwilliams wrote: post #67
moby_click wrote: post #62

Earlier quoted context omitted.

If you require serialized JSON in a specific order, you are not requiring JSON, but some dialect of JSON and that should be clearly communicated. If, for some reason, a client needed a special serialization, i'd ask them for a spec, because the JSON spec does not apply anymore, and be done with it.

I think my argument is a bit different -- sure, this is an interface (maybe to a COBOL copybook in this case?). And yes, it's not "JSON". Agree it's a leaky abstraction. Equally agree it should be documented. Often legacy systems have weirdness after seeing decades of edge-cases. Weirdness that makes them robust in all sorts of unlikely ways. Equally makes them poorly documented, leaky, opaque, and frustrating. But I…

Money down 3 months later:

1) the gateway or more likely something behind it starts crashing for memory errors when someone is serializing some stupidly large array into it

2) using ordered vs non-ordered keys on input changes the behavior and fixes it

3) enabling this checkbox to prevent it fixes the issue and guards against it happening again

4) everyone has forgotten about this web weenies inquiry into the issue

5) due to #4, it takes like 3 weeks of system crashes and hairy debugging to find the cause

6) this guy is long gone, having ridden off into the sunset of smugness

Also:

1) fixing the serialization-dependent memory allocation 4 layers deep on the back-end to allow things to operate safely without this checkbox requires a complex change to several other components and associated system-wide validation testing which would take: drumroll "9 people 6 months to complete"

2) What is the point of this javadoc reference and how exactly does it relate to the issue at hand? Here's a random code doc reference too!: https://pymotw.com/3/collections/ordereddict.html and here also a discussion about impacts: https://mail.python.org/pipermail/python-dev/2016-September/...

Re: The Order of the JSON

#94

Post by ken »

Someone wrote: post #49

Next installment: how flipping an innocuous switch introduced a subtle bug that was silent for years and cost us millions. You can’t just flip that switch, run ”a client to post the JSON to that instance” , see that test “worked just fine” , and call it a day. The POST might just store it, for later processing to wreak havoc (say by ignoring a value that isn’t in the expected place in the JSON), or only rarely seen J…

In other words: why GUI configuration systems should allow comments, just like text config files do.

Re: The Order of the JSON

#95

Post by johnchristopher »

Someone wrote: post #49

Next installment: how flipping an innocuous switch introduced a subtle bug that was silent for years and cost us millions. You can’t just flip that switch, run ”a client to post the JSON to that instance” , see that test “worked just fine” , and call it a day. The POST might just store it, for later processing to wreak havoc (say by ignoring a value that isn’t in the expected place in the JSON), or only rarely seen J…

I wonder if the author documented his changes to the infrastructure (just like it was documented that the feature was enabled and could or couldn't be switched).

Re: The Order of the JSON

#96

Post by ghc »

ken wrote: post #94
Someone wrote: post #49

Next installment: how flipping an innocuous switch introduced a subtle bug that was silent for years and cost us millions. You can’t just flip that switch, run ”a client to post the JSON to that instance” , see that test “worked just fine” , and call it a day. The POST might just store it, for later processing to wreak havoc (say by ignoring a value that isn’t in the expected place in the JSON), or only rarely seen J…

In other words: why GUI configuration systems should allow comments, just like text config files do.

Underrated idea. Never seen this, but I would kill for the ability to add comments to configuration settings or even log changes with commit messages.

Re: The Order of the JSON

#97

Post by roenxi »

dtech wrote: post #87
Someone wrote: post #49

Next installment: how flipping an innocuous switch introduced a subtle bug that was silent for years and cost us millions. You can’t just flip that switch, run ”a client to post the JSON to that instance” , see that test “worked just fine” , and call it a day. The POST might just store it, for later processing to wreak havoc (say by ignoring a value that isn’t in the expected place in the JSON), or only rarely seen J…

How do you justify ever changing anything with that attitude? This change made parsing more lenient which is generally considered fine [1] and made the software actually follow the spec, since it specifies object entries are unordered. [1] https://en.wikipedia.org/wiki/Robustness_principle

The target culture would be to justify the change by saying "the reason this was implemented is X but X no longer holds". Anything else is an indicator of change without understanding; which is likely to lead to unforeseen results.

The robustness principle is a powerful guideline for interface design; not an excuse to turn off validations that someone else has put in place. If the person who designed the interface wasn't ready for something, principles won't make the software work.

Re: The Order of the JSON

#98

Post by patrickthebold »

dtech wrote: post #88
lilyball wrote: post #27

The tweet at the top of the article says > This so far out of the spec it makes my ankles hurt. This is not in fact out of spec. The JSON spec does not define semantics here but instead quite explicitly leaves it up to the JSON processor and data interchange spec for what to do about ordering of objects.

> This is not in fact out of spec. The JSON spec does not define semantics [...] for what to do about ordering of objects. What? It is literally on the first page of json.org and section 1 of RFC 7159 [1] > An object is an unordered set of name/value pairs. > An object is an unordered collection of zero or more name/value pairs [1] https://tools.ietf.org/html/rfc7159#section-1

There are multiple standards. https://www.ecma-international.org/publications/standards/Ec... Is more relaxed.

>The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.

Also it's pretty clear that the keys must have an order going over the wire. And JavaScript objects (which aren't unrelated to JSON have an order now) https://www.stefanjudis.com/today-i-learned/property-order-i...

Re: The Order of the JSON

#99

Post by Ididntdothis »

dec0dedab0de wrote: post #91
Ididntdothis wrote: post #5

This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

I think stuff likes this is the real price of not hiring really good people. I think stuff like this is why decent developers don't become "really good" when working in these environments. If you have a culture of letting people figure things out, and forgiving mistakes, then you'll end up with better engineers. On the other hand if you have a culture of protecting "territory", and blame then you'll get 6 months for…

“I think stuff like this is why decent developers don't become "really good" when working in these environments”

Totally agree. I feel bad for a lot of the young devs who are exposed to daily micromanagement and stand ups and the pressure to constantly deliver something. They don’t get the opportunity to make mistakes and learn from them.

Post reply on HN