4 ms·

I don't know about their code quality, but we consume some of their data via APIs and they periodically randomly change their non-nullable data types to nullabl

I don't know about their code quality, but we consume some of their data via APIs and they periodically randomly change their non-nullable data types to nullable. Fun times hotfixing those in prod.

perfmode 10y ago
When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable. You should write a parser that fails gracefully if it receives unexpected input. It's the robustness principle. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
- Drdrdrq 10y ago
  You're missing the point. Sure, you should make it fil gracefully on unexpected input. But Google shouldn't change APIs in a way hat causes 3rd party apps to fail at all.
  - perfmode 10y ago
    Third party apps wouldn't fail if they were correct in the first place. Failing gracefully on unexpected input is the way a competent engineer would structure their program.
    - deleted 10y ago
      [deleted]
    - ethbro 10y ago
      Is there a functional difference between "my production code suddenly stopped processing work because it rejected a newly nullable input value" vs "my production code suddenly stopped processing work because it crashed on a newly nullable input value"?
      - protomyth 10y ago
        If the crash gives an attack vector for a security threat then there is. Personally, "Be conservative in what you do, be liberal in what you accept from others" is a bad policy in the modern world. It should be "Be conservative in what you do, be strict as if you don't trust them in what you accept from others".
        ethbro 10y ago
        That's a valid point if it's security-critical. My initial response was with regards to grandparent comments arguing over semantics, when the end results in both cases was "successful processing ceased because of an API change."
        yawaramin 10y ago
        'Liberal in what you accept from others' in this case would mean being prepared to handle nullable JSON fields.
      - klodolph 10y ago
        Ideally it's more like "my production code skipped over 1% of batch jobs because it didn't expect the null values" or something like that. Handling errors gracefully is a bit of an art unto itself.
        perfmode 10y ago
        Indeed it is an art.
      - noir_lord 10y ago
        production code that rejects a suddenly nullable input value is more deterministic than "something crashed" and can be handled better (triggering a watchkeeper, notification) rather than relying on someone paying attention to the crash logs.
    - Drdrdrq 10y ago
      "Failing gracefully" is still failing. I don't want my app to fail, gracefully or otherwise.
- squeaky-clean 10y ago
  > When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable. I have to work with their APIs often (as well as Amazon, Facebook and a couple other big players, they're all equally awful). Their documentation will tell you a type is an integer and will never be null. They will do this for 3 months, and then change it to send a string that can be nullable or empty string, without telling you or updating API versions. It goes beyond robustness. It's the "BigCorp will actively lie to you in their documentation" principle.
captn3m0 10y ago
Funny you point this out. Google's JSON Style guidelines[1] say this: >If a property is optional or has an empty or null value, consider dropping the property from the JSON, unless there's a strong semantic reason for its existence. [1]: https://google.github.io/styleguide/jsoncstyleguide.xml?showone=Empty/Null_Property_Values#Empty/Null_Property_Values https://google.github.io/styleguide/jsoncstyleguide.xml?show...
- perfmode 10y ago
  That's a different issue. The commenter is referring to keys that can take on null. This style guide entry suggests a course of action in the event that one of these keys currently has a null value. The style guide isn't prohibiting nullable keys.
walshemj 10y ago
yes some of their api's and tools are a bit shoddy eg unable to parse a xml sitemap to spec and that spec was only a 3 page RFC!

I don't know about their code quality, but we consume some of their data via APIs and they periodically randomly change their non-nullable data types to nullable. Fun times hotfixing those in prod.

perfmode 10y ago

When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable. You should write a parser that fails gracefully if it receives unexpected input. It's the robustness principle. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle

Drdrdrq 10y ago
You're missing the point. Sure, you should make it fil gracefully on unexpected input. But Google shouldn't change APIs in a way hat causes 3rd party apps to fail at all.
- perfmode 10y ago
  Third party apps wouldn't fail if they were correct in the first place. Failing gracefully on unexpected input is the way a competent engineer would structure their program.
  - deleted 10y ago
    [deleted]
  - ethbro 10y ago
    Is there a functional difference between "my production code suddenly stopped processing work because it rejected a newly nullable input value" vs "my production code suddenly stopped processing work because it crashed on a newly nullable input value"?
    - protomyth 10y ago
      If the crash gives an attack vector for a security threat then there is. Personally, "Be conservative in what you do, be liberal in what you accept from others" is a bad policy in the modern world. It should be "Be conservative in what you do, be strict as if you don't trust them in what you accept from others".
      - ethbro 10y ago
        That's a valid point if it's security-critical. My initial response was with regards to grandparent comments arguing over semantics, when the end results in both cases was "successful processing ceased because of an API change."
      - yawaramin 10y ago
        'Liberal in what you accept from others' in this case would mean being prepared to handle nullable JSON fields.
    - klodolph 10y ago
      Ideally it's more like "my production code skipped over 1% of batch jobs because it didn't expect the null values" or something like that. Handling errors gracefully is a bit of an art unto itself.
      - perfmode 10y ago
        Indeed it is an art.
    - noir_lord 10y ago
      production code that rejects a suddenly nullable input value is more deterministic than "something crashed" and can be handled better (triggering a watchkeeper, notification) rather than relying on someone paying attention to the crash logs.
  - Drdrdrq 10y ago
    "Failing gracefully" is still failing. I don't want my app to fail, gracefully or otherwise.
squeaky-clean 10y ago
> When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable. I have to work with their APIs often (as well as Amazon, Facebook and a couple other big players, they're all equally awful). Their documentation will tell you a type is an integer and will never be null. They will do this for 3 months, and then change it to send a string that can be nullable or empty string, without telling you or updating API versions. It goes beyond robustness. It's the "BigCorp will actively lie to you in their documentation" principle.

captn3m0 10y ago

Funny you point this out. Google's JSON Style guidelines[1] say this: >If a property is optional or has an empty or null value, consider dropping the property from the JSON, unless there's a strong semantic reason for its existence. [1]: https://google.github.io/styleguide/jsoncstyleguide.xml?showone=Empty/Null_Property_Values#Empty/Null_Property_Values https://google.github.io/styleguide/jsoncstyleguide.xml?show...

perfmode 10y ago
That's a different issue. The commenter is referring to keys that can take on null. This style guide entry suggests a course of action in the event that one of these keys currently has a null value. The style guide isn't prohibiting nullable keys.

walshemj 10y ago

yes some of their api's and tools are a bit shoddy eg unable to parse a xml sitemap to spec and that spec was only a 3 page RFC!