13 ms·

You missed the snakes and ladders game of following googles out of date documentation. "You're doing it wrong, we deprecated that last year, I know we haven't

You missed the snakes and ladders game of following googles out of date documentation. "You're doing it wrong, we deprecated that last year, I know we haven't yet updated the 4 separate places in which the same thing is documented all in a different context and different way. We really should fix that but we're busy coding. Did you know we're all PhDs at Google?" What?!?!? You're using the Google console version 3? Why? That feature isn't implemented there. Stupid you. You're MEANT to be using our new Google console version X. Why are you using our old one? Also you missed the 16 hours you'll spend trying work out why something isn't working only to find it's actually been changed or taken out of the Google developer console, without any trace or notice left in the code to say'we moved/removed the feature that you expected to be here.' Really you should ask Google for help on StackOverflow which is now the official Google channel for ignoring support questions, and where your question will within seconds be down voted, derided and deleted by the StackOverflow Community,saving Google the effort of not reading and ignoring your question about how to resolve the catastrophic failure of your software. Seriously though, why not entrust your critical systems to such capable hands?

wslh 11y ago
Also, it seems Google's Page Rank is sometimes optimized to show old documentation instead of the most related and current one. this is natural because there are more links pointing to the old one but needs to be fixed.
jfoster 11y ago
It's a shame about the tone of this post. I think it might not suit HN. As a Google Cloud customer, though, I think you do manage to be spot on about a lot of the things Google are doing wrong when it comes to the Cloud Platform. Today I came across an App Engine SDK bug that was reported almost 5 years ago, has a several years old patch in the comments, and still hasn't been remedied by Google. App Engine users who encounter it have to find the bug, apply the patch to the SDK, and repeat that upon each SDK update.
- dlor 11y ago
  Could you send me a link to the issue? I can hopefully get that fixed.
  - throwaway2349 11y ago
    TIL: Google doesn't know where its own bug database is.
  - d0vs 11y ago
    Not OP but here's another example: https://code.google.com/p/googleappengine/issues/detail?id=6469 https://code.google.com/p/googleappengine/issues/detail?id=6... The patch is trivial
    - nulltype 11y ago
      urlfetch is the worst, at least MVM will be getting rid of that. I would just use the socket api instead of urlfetch, like I do here: https://code.google.com/p/googleappengine/issues/detail?id=601&q=post%20delete&colspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component https://code.google.com/p/googleappengine/issues/detail?id=6...
      - jfoster 11y ago
        Wow. That's a classic example of the lack of investment into App Engine. Filed 7 years ago, acknowledged, and still open with no one assigned to it.
        nulltype 11y ago
        It's true, if Google wants GCP to be good, they will have to use it themselves. I definitely don't trust public bug reports to fix issues. At least if you have a support plan they are good at responding and sometimes fixing things. There's no way anyone in Google uses URLFetch, which explains why it's so bad.
  - 11y ago
ianchildress 11y ago
I signed up just to reply to this post and say THIS is exactly how our development team (which write in Go) feels. This post could not be more accurate in terms of trying to deal with the outdated documentation. #1 The documentation is often months and many versions old. #2 is the fact that app engine instances have to connect to back end compute engine instances using a public IP is unbelievable. The solution for an app engine instance to communicate with your compute engine app is to use their PubSub api system. To get the PubSub api system to work, see #1. The examples are months outdated and you no longer use the appengine.Context to create your OAuth token, but instead now use context.Context which you learn by going through github issue comments. Google needs to recognize their great deficiency in documentation to be considered in the same tier as AWS.
- mimming 11y ago
  (Google DevRel here) We recognize that there's out of date stuff in there :\ This is obviously on us, but if you see something wrong, please use that little 'send feedback' link the upper right corner, as demonstrated in this gifly: http://gifly.com/3SA5/ http://gifly.com/3SA5/ I just set up an alert set up for feedback with a table flip in the description, so those go right to my inbox.
  - photonios 11y ago
    Great to hear they go straight to your inbox. Usually I have the feeling the stuff that is submitted through the 'Feedback' buttons is never read.
    - mimming 11y ago
      Just to clarify, they all go to someone's inbox. Only the table flip ones go to mine.
    - TheIronYuppie 11y ago
      (Googler here) In fact, every piece of feedback goes directly to our bug tracking, and a human being looks at every single one. That's not an excuse, and doesn't mean that we can't do better, but we track it all. The biggest problem is the conversion from item in the bug list to actual changes, and we're working on that!
philip1209 11y ago
We started StaffJoy infrastructure on GCE. The per-minute billing had the potential to be a huge cost-saver with the optimization software that we use for scheduling because doubling the number of CPU cores (at twice the hourly cost) halved the calculation time, resulting in no overall cost increase but faster data. I switched from GCE to AWS when we had a build break because Google released a new command line utility for deploys, immediately yanked the previous CLI causing it to 404, and provided no way of pulling the "latest" CLI. (We needed to reinstall the CLI for each build because we used CircleCI). It was part of a long string of frustrations of getting basic workflows to work.
- skj 11y ago
  It looks like https://circleci.com/docs/deploy-google-app-engine https://circleci.com/docs/deploy-google-app-engine explicitly hard-coded an old version of the appengine SDK. And by old, I don't mean not-quite-the-latest, I mean quite old. When it was yanked, it was not the previous CLI, it was the CLI from a deprecation-policy-timelimit ago.
  - dwwoelfel 11y ago
    That's just sample code to demonstrate how one would install appengine on Circle. The URL in the example is a placeholder for the one you would get from https://cloud.google.com/appengine/downloads https://cloud.google.com/appengine/downloads.
mimming 11y ago
Google Cloud Developer Relations here :) Thanks for the feedback and stuff. I empathize with your frustration. We're listening to threads like these, and workin' hard to make stuff better. Also, next time you're frustrated with Google Cloudy stuff, feel free to vent to me. It's like unfiltered usability studies.
- forgottenacc56 11y ago
  OK so if you're from Google and you say Goigle is listening, here's a question I've never heard and answer to: how come Google has such terrible support for Python 3?
  - mimming 11y ago
    This is probably outside of my area of expertise, but I'll see if I can dig up an answer. I need more context though. Where are you trying to use Python 3 and what problem are you trying to solve with it?
    - mimming 11y ago
      I've never done much Python stuff at all (It's a great language, I just never used it on a major project). I just spent the last hour catching up on the chronicles of Python 2 -> Python 3 (not just at Google, but everywhere). Sorry, but here's my answer: http://i.imgur.com/tZOS8.gif http://i.imgur.com/tZOS8.gif
forgottenacc56 11y ago
I just want to say this comment has 73 upvotes/points.
jjjjoe 11y ago
(Google Cloud Support here) The across-the-board guidance to go to StackOverflow is not working, and we get that. It's not just that system administration questions get downvoted on StackOverflow (which I think is the parent's point) but that StackExchange isn't good for general discussion. We (support) are trying to be much more clear that free support is not "StackOverflow or nothing." We recently updated our "community" support page at https://support.google.com/cloud/answer/3466163 https://support.google.com/cloud/answer/3466163 to lay out all of the community support options in one place. Bottom line: everything listed on that page has Googlers actively participating. This includes groups, StackExchange, and issue trackers. There's room for plenty of improvement, the intent is not to ignore you.
- hoodoof 11y ago
  Google should have a central support forum and try to focus all the questions into one place. StackOverflow should not be on your support list at all, for the reasons raised. Having said that, Google should still be on SO answering questions that end up there. What Google needs to understand is that its long standing public reputation that it has built is an organisation that actively tries to avoid providing support - ever since Google started it has tried to avoid support. That is now the reputation that Google carries into its efforts to woo the developer community. Google has to be extraordinarily good at developer support to dispel the baseline assumption that developers have that Google really (genuinely) wants to avoid dealing with support questions. There's a level of cluelessness to Google's support strategy that is concerning. Why, for goodness sake, would it EVER look like a good idea to push support to StackOverflow? Who is doing the thinking behind that sort of decision? It is self evident that Google's support interests and StackOverflow are not the same thing. It's the sort of decision made without really considering the detail, and that is the point about Google's support - it's an afterthought. Kind of like washing the dishes after dinner is eaten - has to be done but we're not enthused about it. And in the end, lack of support is a showstopper for using a cloud computing platform. If the support looks sketchy then it just isn't worth risking your business by using that platform.
  - SiVal 11y ago

wslh 11y ago

Also, it seems Google's Page Rank is sometimes optimized to show old documentation instead of the most related and current one. this is natural because there are more links pointing to the old one but needs to be fixed.

jfoster 11y ago

It's a shame about the tone of this post. I think it might not suit HN. As a Google Cloud customer, though, I think you do manage to be spot on about a lot of the things Google are doing wrong when it comes to the Cloud Platform. Today I came across an App Engine SDK bug that was reported almost 5 years ago, has a several years old patch in the comments, and still hasn't been remedied by Google. App Engine users who encounter it have to find the bug, apply the patch to the SDK, and repeat that upon each SDK update.

dlor 11y ago
Could you send me a link to the issue? I can hopefully get that fixed.
- throwaway2349 11y ago
  TIL: Google doesn't know where its own bug database is.
- d0vs 11y ago
  Not OP but here's another example: https://code.google.com/p/googleappengine/issues/detail?id=6469 https://code.google.com/p/googleappengine/issues/detail?id=6... The patch is trivial
  - nulltype 11y ago
    urlfetch is the worst, at least MVM will be getting rid of that. I would just use the socket api instead of urlfetch, like I do here: https://code.google.com/p/googleappengine/issues/detail?id=601&q=post%20delete&colspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component https://code.google.com/p/googleappengine/issues/detail?id=6...
    - jfoster 11y ago
      Wow. That's a classic example of the lack of investment into App Engine. Filed 7 years ago, acknowledged, and still open with no one assigned to it.
      - nulltype 11y ago
        It's true, if Google wants GCP to be good, they will have to use it themselves. I definitely don't trust public bug reports to fix issues. At least if you have a support plan they are good at responding and sometimes fixing things. There's no way anyone in Google uses URLFetch, which explains why it's so bad.
- 11y ago

ianchildress 11y ago

I signed up just to reply to this post and say THIS is exactly how our development team (which write in Go) feels. This post could not be more accurate in terms of trying to deal with the outdated documentation. #1 The documentation is often months and many versions old. #2 is the fact that app engine instances have to connect to back end compute engine instances using a public IP is unbelievable. The solution for an app engine instance to communicate with your compute engine app is to use their PubSub api system. To get the PubSub api system to work, see #1. The examples are months outdated and you no longer use the appengine.Context to create your OAuth token, but instead now use context.Context which you learn by going through github issue comments. Google needs to recognize their great deficiency in documentation to be considered in the same tier as AWS.

mimming 11y ago
(Google DevRel here) We recognize that there's out of date stuff in there :\ This is obviously on us, but if you see something wrong, please use that little 'send feedback' link the upper right corner, as demonstrated in this gifly: http://gifly.com/3SA5/ http://gifly.com/3SA5/ I just set up an alert set up for feedback with a table flip in the description, so those go right to my inbox.
- photonios 11y ago
  Great to hear they go straight to your inbox. Usually I have the feeling the stuff that is submitted through the 'Feedback' buttons is never read.
  - mimming 11y ago
    Just to clarify, they all go to someone's inbox. Only the table flip ones go to mine.
  - TheIronYuppie 11y ago
    (Googler here) In fact, every piece of feedback goes directly to our bug tracking, and a human being looks at every single one. That's not an excuse, and doesn't mean that we can't do better, but we track it all. The biggest problem is the conversion from item in the bug list to actual changes, and we're working on that!

philip1209 11y ago

We started StaffJoy infrastructure on GCE. The per-minute billing had the potential to be a huge cost-saver with the optimization software that we use for scheduling because doubling the number of CPU cores (at twice the hourly cost) halved the calculation time, resulting in no overall cost increase but faster data. I switched from GCE to AWS when we had a build break because Google released a new command line utility for deploys, immediately yanked the previous CLI causing it to 404, and provided no way of pulling the "latest" CLI. (We needed to reinstall the CLI for each build because we used CircleCI). It was part of a long string of frustrations of getting basic workflows to work.

skj 11y ago
It looks like https://circleci.com/docs/deploy-google-app-engine https://circleci.com/docs/deploy-google-app-engine explicitly hard-coded an old version of the appengine SDK. And by old, I don't mean not-quite-the-latest, I mean quite old. When it was yanked, it was not the previous CLI, it was the CLI from a deprecation-policy-timelimit ago.
- dwwoelfel 11y ago
  That's just sample code to demonstrate how one would install appengine on Circle. The URL in the example is a placeholder for the one you would get from https://cloud.google.com/appengine/downloads https://cloud.google.com/appengine/downloads.

mimming 11y ago

Google Cloud Developer Relations here :) Thanks for the feedback and stuff. I empathize with your frustration. We're listening to threads like these, and workin' hard to make stuff better. Also, next time you're frustrated with Google Cloudy stuff, feel free to vent to me. It's like unfiltered usability studies.

forgottenacc56 11y ago
OK so if you're from Google and you say Goigle is listening, here's a question I've never heard and answer to: how come Google has such terrible support for Python 3?
- mimming 11y ago
  This is probably outside of my area of expertise, but I'll see if I can dig up an answer. I need more context though. Where are you trying to use Python 3 and what problem are you trying to solve with it?
  - mimming 11y ago
    I've never done much Python stuff at all (It's a great language, I just never used it on a major project). I just spent the last hour catching up on the chronicles of Python 2 -> Python 3 (not just at Google, but everywhere). Sorry, but here's my answer: http://i.imgur.com/tZOS8.gif http://i.imgur.com/tZOS8.gif

forgottenacc56 11y ago

I just want to say this comment has 73 upvotes/points.

jjjjoe 11y ago

(Google Cloud Support here) The across-the-board guidance to go to StackOverflow is not working, and we get that. It's not just that system administration questions get downvoted on StackOverflow (which I think is the parent's point) but that StackExchange isn't good for general discussion. We (support) are trying to be much more clear that free support is not "StackOverflow or nothing." We recently updated our "community" support page at https://support.google.com/cloud/answer/3466163 https://support.google.com/cloud/answer/3466163 to lay out all of the community support options in one place. Bottom line: everything listed on that page has Googlers actively participating. This includes groups, StackExchange, and issue trackers. There's room for plenty of improvement, the intent is not to ignore you.

hoodoof 11y ago
Google should have a central support forum and try to focus all the questions into one place. StackOverflow should not be on your support list at all, for the reasons raised. Having said that, Google should still be on SO answering questions that end up there. What Google needs to understand is that its long standing public reputation that it has built is an organisation that actively tries to avoid providing support - ever since Google started it has tried to avoid support. That is now the reputation that Google carries into its efforts to woo the developer community. Google has to be extraordinarily good at developer support to dispel the baseline assumption that developers have that Google really (genuinely) wants to avoid dealing with support questions. There's a level of cluelessness to Google's support strategy that is concerning. Why, for goodness sake, would it EVER look like a good idea to push support to StackOverflow? Who is doing the thinking behind that sort of decision? It is self evident that Google's support interests and StackOverflow are not the same thing. It's the sort of decision made without really considering the detail, and that is the point about Google's support - it's an afterthought. Kind of like washing the dishes after dinner is eaten - has to be done but we're not enthused about it. And in the end, lack of support is a showstopper for using a cloud computing platform. If the support looks sketchy then it just isn't worth risking your business by using that platform.
- SiVal 11y ago