[google-appengine] Re: Ongoing App Engine Commitment?

['Jesse Scherer (Google Cloud Support)' via Google App Engine]

Hi Tim, sorry for the late reply but I've been working on a novella for you 
:-)

I'm a technical program manager from the GCP support team. I work on 
community-facing support (which is just part of our support 
 offering) for all of GCP, including App 
Engine.

On Friday, March 31, 2017 at 8:39:29 AM UTC-4, Tim Consolazio wrote:
>
> I've been noticing some things:
>
- App Engine support shunted over to Stack Overflow (so...a non-Google 
> community resource).
>

It turns out that if you search for a particular error message from one of 
our products, you're very likely to see a Stack Overflow question about 
that very message among the first results. So yes, we lose some control, 
but the Stack Overflow community is pretty good at maintaining a high 
quality Q&A site. Given that our goal is for every interaction to help as 
many people as possible, it makes sense to go where the users are.

I should point out that we actively monitor this Google Group and bug 
reports on issuetracker.google.com, not just Stack Overflow. The difference 
is in focus: Stack Overflow is a place for "I know what I want to do, but 
not quite how" type Q&A.

- Mail API pretty much deprecated (no more quota expansions, 100 email 
> limit). 
>

You're right, that's not great. A while ago, Kim Lewandowski mentioned 
 
that we're investigating a solution to the issues that plague the current 
mail API. There's currently a thread going about this; please take Kim up 
on her offer 
 
to share use cases.
 

> - Deprecation of Channel API (sure we have Firebase, but still...what's 
> the commitment to that?)
>

Since I work for support and not product management I can only speak 
informally, but Firebase is a product with a lot of integrations across 
Google products. This isn't one I'd worry about. Also notice the byline 
 and linked article 
 on Firebase's homepage 
pointing out the integration of Firebase and Cloud Functions.
 

> - No Java 8 (and 7 was a long time in coming).
>

I think Jeff already covered this one :-)
 

> - Gradual deprecation of local SDK in favor of remote/virtual dev (which 
> to me is unacceptable, I depend on that local SDK). 
>

My colleague Justin Beckwith talked about this 
 
a few months ago: we understand that local development is an important 
feature and are looking at how to enable it in gcloud. But since it's not 
ready yet, we do continue to maintain the standalone SDK.
 

>
> I frequently recommend App Engine (and I've built quite a few apps on it). 
> I've been a rogue evangelist of the platform for years (since it was 
> released in fact), and have been contracted by Google three times to build 
> applications using it. So I'm not a hater in any way. 
>
> But I can't look at these events (particularly the Stack Overflow thing) 
> and ignore the impression that App Engine is beginning to feel more like a 
> side project rather than a commercial offering with full resource 
> commitment by the vendor. 
>

I've spoken to your point about Stack Overflow already, but I hope you're 
not reading too much into things like Datastore becoming a first-class 
product instead of an App Engine-only feature. That sort of transition 
acknowledges the reality there are several models for cloud compute, and 
that a lot of features which launched as part of App Engine (when App 
Engine was our sole compute offering) make just as much sense when used 
with containers, or VMs, or Cloud Functions.  
 

>
> Curious about a formal statement of commitment here, and a complete 
> roadmap of what we can reasonably expect over say, the next two years. 
>
>
We've mentioned this before, but there are a lot of reasons for us to be 
tight-lipped about our exact roadmap. But I hope that seeing real progress 
like the Flexible Environment exiting Beta or upcoming Java 8 on Standard 
 
demonstrate our commitment to App Engine.
 
Regards,
Jesse

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/12559c6a-764d-4084-a7e2-83a6c71297ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Ongoing App Engine Commitment?

[Jeff Schnitzer]

For multiple years now I have been using CircleCI to deploy multiple
projects to GAE. My deploys are: “git checkout production; git merge
master; git push”. It’s super easy and pretty well documented at Circle’s
website. I’m happy to share my configs too.

“push to deploy” doesn’t seem like a CI concern not a Google concern, no?
At the very least I don’t want anything going to prod that hasn’t been
tested.

Jeff

On Thu, Apr 6, 2017 at 5:14 AM, Sivaprakash Saripalli 
wrote:

> One more point pointing in this direction is continous integration or lack
> of support for it. They have removed support for Push-to-deploy (been 2
> years now I think). I couldn't even find documentation related to wiring up
> App Engine with Jenkins while there is ample documentation for Google
> Container Engine.
>
> If Container Engine/Kubernetes is the future, they should come out and say
> so.
>
> On Friday, March 31, 2017 at 6:09:29 PM UTC+5:30, Tim Consolazio wrote:
>>
>> I've been noticing some things:
>>
>> - App Engine support shunted over to Stack Overflow (so...a non-Google
>> community resource).
>> - Mail API pretty much deprecated (no more quota expansions, 100 email
>> limit).
>> - Deprecation of Channel API (sure we have Firebase, but still...what's
>> the commitment to that?)
>> - No Java 8 (and 7 was a long time in coming).
>> - Gradual deprecation of local SDK in favor of remote/virtual dev (which
>> to me is unacceptable, I depend on that local SDK).
>>
>> I frequently recommend App Engine (and I've built quite a few apps on
>> it). I've been a rogue evangelist of the platform for years (since it was
>> released in fact), and have been contracted by Google three times to build
>> applications using it. So I'm not a hater in any way.
>>
>> But I can't look at these events (particularly the Stack Overflow thing)
>> and ignore the impression that App Engine is beginning to feel more like a
>> side project rather than a commercial offering with full resource
>> commitment by the vendor.
>>
>> Curious about a formal statement of commitment here, and a complete
>> roadmap of what we can reasonably expect over say, the next two years.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-appengine.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-appengine/41de0f0f-d090-432a-9cca-
> 107be2f838f0%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CADK-0uj5e%2BiUwenwyw4NAX6gj8KKTXg9S9DOeJtNgPOFjWeUTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: gcloud beta logging read creates huge log files in .config

[Julian Bunn]

Hello,

The size of the files in the ~/.config subdir appear to scale with the
number of logs downloaded by the gcloud tool.

We are downloading a day's worth of logs at a time, for a busy application
which produces around 750k log entries per day.

(Downloading this many log entries takes at least 10 hours with the gcloud
tool, which is another problem entirely!)

Right now I am simply deleting the log files created in the .config subdir,
after our download job finishes, but this is a rather crude fix!

Thanks,
Julian

On Thu, Apr 6, 2017 at 1:58 PM, 'George (Cloud Platform Support)' via
Google App Engine  wrote:

> Hello Julian,
>
> We could not reproduce the issue locally. The files in our linux machine’s
> ~/.config/gcloud/logs directory are reasonably small.
>
> You may attempt to reduce the size of your file by applying filtering more
> aggressively. Details on filter setup are to be found on the “Command Line
> Interface” documentation page
> .
>
> Hoping this is of help to you, I remain at your disposal for related
> questions.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google App Engine" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/google-appengine/8jY242lvAHk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-appengine.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-appengine/ae255ffc-6ae9-47d0-afed-
> 428c65911c98%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAAxkZQtnhcvTU8c8-_6%3DZ1VD-6Mp%2BKKndF3vQ09Vqma7s%3Dn5ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: gcloud beta logging read creates huge log files in .config

['George (Cloud Platform Support)' via Google App Engine]

Hello Julian, 

We could not reproduce the issue locally. The files in our linux machine’s 
~/.config/gcloud/logs directory are reasonably small. 

You may attempt to reduce the size of your file by applying filtering more 
aggressively. Details on filter setup are to be found on the “Command Line 
Interface” documentation page 
. 

Hoping this is of help to you, I remain at your disposal for related 
questions. 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/ae255ffc-6ae9-47d0-afed-428c65911c98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Issue with a new SSL Cert (You must verify ownership of this certificate's domain(s)in order to upload it)

[Arun Shanker Prasad]

Thanks Attila.

We also ended up doing the same, I removed the existing domain and added it 
back in again.

One important thing to note is that we need to be doing this from the same 
account that is linked to the domain in webmaster tools, that part is also 
confusing and not clearly mentioned anywhere.

On Tuesday, 28 March 2017 10:28:35 UTC+5:30, Attila-Mihaly Balazs wrote:
>
> Yep, the SSL interface is confusing (like, why do you have to verify the 
> subdomain when you already verified the root domain? In what universe do 
> you have control of the root domain but don't control the subdomain?).
>
> Anyway, when adding the domain to appengine, at the second step you *can* 
> remove the www one (I've done this Monday actually). So the workflow is 
> something like:
>
> - go to the setup page 
> https://console.cloud.google.com/appengine/settings/domains?project= project>
> - click "Add custom domain"
> - select "Verify new domain" from the dropdown
> - after completing verification in the webmaster tools, click the refresh 
> button
> - now it will display two text boxes (as you've said) one with "
> www.foo.com" and one with "foo.com" but you can use the X on "www.foo.com" 
> (on the right end) to remove it and leave only "foo.com" (or the other 
> way around).
>
> Ie. you don't have to add both domains suggested by Google.
>
> And a good point about having to be the verified of the domain in 
> Webmaster tools.
>
> Cheers,
> Attila
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/efcd9cc5-52d7-48fd-8814-3bc6d7cc2f10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Downloading Logs

['Andrew Teall' via Google App Engine]

Hi,
Over the past couple weeks we've started recieving this error message when 
trying to download logs from appengine:

2017-04-06 18:26:55,961 INFO appcfg.py:1116 Request with offset None. 
2017-04-06 18:26:56,898 INFO appengine_rpc_httplib2.py:303 Too many retries 
for url 
https://appengine.google.com/api/request_logs?app_id=myflashpanel&include_vhost=False&limit=1000&module=default&no_header=1&severity=0&version=a
 
Error 500: --- begin server output ---


Server Error (500)

A server error has occurred.
--- end server output ---


How can we remedy it and prevent it from happening in the future. I've 
already turned off the process that gathers these logs.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/40e59353-41be-45d8-8af0-423ccf8416fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Incoming request dalyed by 4+ seconds

['Nicholas (Google Cloud Support)' via Google App Engine]

While the time spans you describe do sound fairly long considering the 
related actions, there isn't really enough information to know exactly what 
the root cause might be.

I would normally recommend consulting Stackdriver Trace 
 to get more reliable 
statistics on the where the bulk of your application time is being spent. 
 This will likely reveal exact times for calls to memcache, Datastore and 
the URL Fetch service.  As for the overall time, you may look at the 
*protoPayload.latency* in the Stackdriver Logging log entry for your 
service to get the time during which the request was being handled by your 
application.

To compare the above measurements with the end-user experience, you may 
want to get a few HAR captures 
 of requests to your 
application from a given client.  Studying this as well will allow you to 
compare the total time for the request/response exchange to the time spent 
by your application receiving/responding to the client request.

   - Do you have any more specific time frames for when you noticed such 
   latency?
   - Are you using the standard or flexible environment?
   - Where is your application serving and where are client requests coming 
   from?
   - How are you measuring the time taken for the various operations you 
   listed?
   - Are the more significant latencies specific to a particular service, 
   endpoint, URL, etc.?
   
Regarding charges with App Engine front-end instance hours, there was a known 
issue  with charges not being 
applied correctly.  I would recommend following that public issue closely 
for updates.  You may also receive communications if it was determined that 
your project(s) was/were affected.

On Monday, April 3, 2017 at 4:46:03 PM UTC-4, Tomas wrote:
>
> Hello there,
>
> I've noticed that last month was pretty bad for my java apps running on 
> app engine. Almost everything was unbelievably slow:
>
> 1) saving simple java bean into cache consistently takes half second 
> (sometime more)
> 2) saving same bean (4 String fields) into datastore can take 10+ seconds 
> (Using Objectify)
> 3) also my incoming requests are being hold for 5 seconds before they 
> reach my servlet
> 4) looks like external http fetches are also taking more than usual (used 
> to do them in 30-50ms now they take 500ms)
>
> I've been charged with $60 for last month (App engine front-end instances) 
> while usually charge is around $2-3 per app... And it's very hard to trace 
> the reason for a such high charge, for example my trace console wasn't able 
> to load at all etc)...
>
> Does anyone have the similar issue? Also how could I trace the reason, why 
> is the request held 'somewhere' before actually being send to my servlet?
>
> Thanks...
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/633a17a3-948e-423a-9ce7-528c99c5abaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Speech API - word timings

['Nicholas (Google Cloud Support)' via Google App Engine]

Apologies for the internal URL.  The public issue can be accessed here: 
https://issuetracker.google.com/37002743

On Wednesday, April 5, 2017 at 7:46:41 PM UTC-4, Nick (Cloud Platform 
Support) wrote:
>
> Hey Lance,
>
> We're aware of this request although we can't provide any timelines on our 
> work, across any products. If you'd like, you can "star" this issue by 
> hitting "Me Too" in the Public Issue Tracker 
> .
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Tuesday, April 4, 2017 at 4:59:56 AM UTC-4, Lance Dolan wrote:
>>
>> What is the latest news on this feature?
>>
>> We're evaluating Google Speech API as a means for a rather large 
>> solution. Google is more accurate than its competitors, but the competitors 
>> prove word timings. For example, see IBM Watson here, and click the "word 
>> timings" tab (https://speech-to-text-demo.mybluemix.net). It functions 
>> almost exactly as Gene has requested here.
>>
>> For us, knowing word timings is a requirement... To proceed with Google 
>> Speech might require some really hacky weird stuff on our part to determine 
>> timings. We've tested chopping the audio up in to 3 second blocks to create 
>> our own rough estimate of timings, but this dramatically harms the accuracy 
>> as the Google service loses its context for each audio block.
>>
>> On Friday, August 19, 2016 at 11:16:28 AM UTC-7, Nick (Cloud Platform 
>> Support) wrote:
>>>
>>> Hey Gene,
>>>
>>> Final update for now, the issue is filed and will be taken a look at. 
>>>
>>> Have a nice day!
>>>
>>> Cheers,
>>>
>>> Nick
>>> Cloud Platform Community Support
>>>
>>> On Monday, August 8, 2016 at 11:32:28 AM UTC-4, Gene Matocha wrote:

 Hi,

 Just stareted evaluating the Google Speech API. The accuracy is 
 impressive, but it doesn't provide word timings (when in the recording the 
 word occurred)  by default, and I don't see it as a configurable option. 
 Does anyone know if this can be enabled, or may be on the roadmap for a 
 future release?

 Thanks,
 Gene

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/c3eb42fa-762e-4c2b-b433-f11fc295e925%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Ongoing App Engine Commitment?

[Sivaprakash Saripalli]

One more point pointing in this direction is continous integration or lack 
of support for it. They have removed support for Push-to-deploy (been 2 
years now I think). I couldn't even find documentation related to wiring up 
App Engine with Jenkins while there is ample documentation for Google 
Container Engine. 

If Container Engine/Kubernetes is the future, they should come out and say 
so. 

On Friday, March 31, 2017 at 6:09:29 PM UTC+5:30, Tim Consolazio wrote:
>
> I've been noticing some things:
>
> - App Engine support shunted over to Stack Overflow (so...a non-Google 
> community resource).
> - Mail API pretty much deprecated (no more quota expansions, 100 email 
> limit). 
> - Deprecation of Channel API (sure we have Firebase, but still...what's 
> the commitment to that?)
> - No Java 8 (and 7 was a long time in coming). 
> - Gradual deprecation of local SDK in favor of remote/virtual dev (which 
> to me is unacceptable, I depend on that local SDK). 
>
> I frequently recommend App Engine (and I've built quite a few apps on it). 
> I've been a rogue evangelist of the platform for years (since it was 
> released in fact), and have been contracted by Google three times to build 
> applications using it. So I'm not a hater in any way. 
>
> But I can't look at these events (particularly the Stack Overflow thing) 
> and ignore the impression that App Engine is beginning to feel more like a 
> side project rather than a commercial offering with full resource 
> commitment by the vendor. 
>
> Curious about a formal statement of commitment here, and a complete 
> roadmap of what we can reasonably expect over say, the next two years. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/41de0f0f-d090-432a-9cca-107be2f838f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Ongoing App Engine Commitment?

[Tim Consolazio]

Hmm...I'm not sure that you can ever really avoid writing a back end unless 
you are doing only very standard, boilerplate things. How would you do a 
content matched (based on login) retrieval/map/transform of a collection of 
objects without writing back end (or at least, "virtual" backend) code?

On Thursday, April 6, 2017 at 6:48:12 AM UTC-4, dinoboff wrote:
>
> I don't think Firebase is like GAE. GAE managed a backend server in a 
> scalable way; you're still programming a backend application. Firebase on 
> the other end is suppose to get ride of the backend application.
>
> I think Google Cloud Endpoint was trying to solve the same use case than 
> firebase.
>
> The various Server-less platforms (AWS lambda, cloud function) are similar 
> to the original GAE model (before they introduced instances) with a shift 
> away from the REST api. On GAE you map a http handler to an event (http 
> request, pub/sub event, email received, etc...); on Server-less apps you 
> map a function to an event directly. It's a more boilerplate if you're just 
> writing REST API, but I guessing it's more efficient and more elegant for 
> other type of events than HTTP request.
>
> On Sunday, 2 April 2017 19:09:01 UTC+1, pdknsk wrote:
>>
>> You mentioned Firebase. I don't use it, but isn't it fair to say that 
>> Firebase is what App Engine originally meant to be? Might be a piece of the 
>> puzzle.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/83bf4b45-dffe-4f5d-addf-5f234941675d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Ongoing App Engine Commitment?

['dinoboff' via Google App Engine]

I don't think Firebase is like GAE. GAE managed a backend server in a 
scalable way; you're still programming a backend application. Firebase on 
the other end is suppose to get ride of the backend application.

I think Google Cloud Endpoint was trying to solve the same use case than 
firebase.

The various Server-less platforms (AWS lambda, cloud function) are similar 
to the original GAE model (before they introduced instances) with a shift 
away from the REST api. On GAE you map a http handler to an event (http 
request, pub/sub event, email received, etc...); on Server-less apps you 
map a function to an event directly. It's a more boilerplate if you're just 
writing REST API, but I guessing it's more efficient and more elegant for 
other type of events than HTTP request.

On Sunday, 2 April 2017 19:09:01 UTC+1, pdknsk wrote:
>
> You mentioned Firebase. I don't use it, but isn't it fair to say that 
> Firebase is what App Engine originally meant to be? Might be a piece of the 
> puzzle.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/a8a91594-8af0-406f-82ce-5e9d982c4074%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] NSA on Python Frameworks ?

['Alex Martelli' via Google App Engine]

On Thu, Apr 6, 2017 at 8:10 AM, Johan Mutsaerts 
wrote:

> Thanks Alex,
>
> Great you concur on GAE & Python as good choices for the enterprise web
> application developer's toolkit (perhaps a good title for a new book?).
> You seem to be in favor of a best of breed approach in separating template
> engine and framework, which eliminates the need for heavy lifting of full
> frameworks (like Django) in favor of leaner (faster) frameworks ?
>

Yes, jinja2 (while similar to Django templates) is superior, there's no
need to compromise on the templating front.


> I find it difficult to sort candidates in terms of obsolescence,
> popularity (community support), feature set, learning curve, GAE
> compatibility ... e.g.: pylons, pyramid ? webapp2, wbe2py ? jinja2, mako ?
> bottle, flask ?
>

Django's by far the most popular Python web framework -- 1.7M web hits for
a search [python django]. jinja2's also popular, but just 380k hits; flask,
570k. You can do more searches if you want to base your choice on
popularity. Other indications is that there are conferences entirely
devoted to Django but not ones entirely about other Python web frameworks.


> Is Django really the only framework for developers 'on a deadline' ? on
> GAE ? using NDB ? If I read you right, your preference goes to Flask and
> Jinja2 ? Can you elaborate a bit on the why's ?
>

jinja2 gives me complete, accurate control of templating -- I'd never
downgrade to any other templating system (if I am templating server-side at
all -- these days it's often better to write the server side as a REST or
other API server, and do all the UI work, templating or otherwise, on the
Javascript client side on the browser).

As for the framework (templating apart), I think flask is objectively
superior, with a sharp and simple, though powerful, architecture. However
personally I'm more used to webapp2, having used it for years, so if I'm
doing a simple web app I'm more likely to reach for it -- habit's a
powerful force:-). In any case, it will be a lightweight system because I
don't have to "buy into" lots of architectural and design choices imbued in
a rich/heavy framework, but rather can make my own choices depending on
where I'm going to deploy and what (if anything) I need to optimize for.
(Often, e.g for an internal dashboard which will have a few dozen users at
most, there's no optimization needed at all -- then I can emphasize
simplicity and speed of deployment -- just as an example).


>
> Good luck with the book and the conference.
>

Thanks,

Alex



> TIA, Johan
>
>
> Op woensdag 5 april 2017 17:48:04 UTC+2 schreef Alex Martelli:
>>
>> Of course these questions are quite connected with personal opinion, and
>> since I'm the author of "Python in a Nutshell" (3rd edition due out any day
>> now), you can guess where my bias lies:-). Still, FWIW, here are my
>> opinions (hope others chime in!-)...:
>>
>> On Wed, Apr 5, 2017 at 8:21 AM, Johan Mutsaerts 
>> wrote:
>>
>>> Hi,
>>>
>>> Starting your own company is never easy. A dream and a good idea is
>>> needed but not sufficient. In my case, enterprise software development
>>> skills for non-web applications need to be brushed up, so careful choices
>>> to be made:
>>> 1. GAE PaaS : AFAIK great value for little money, it simply works,
>>> always, anywhere, no need for sysops
>>>
>>
>> I concur (but I'm biased on this one too:-).
>>
>>
>>> 2. Python : AFAIK highest productivity language, modular, functional,
>>> object-oriented, popular
>>>
>>
>> Ditto (in fact I'm right now in Florence, Italy, about to present a
>> keynote at Pycon Italia Otto on Friday:-).
>>
>>
>>> 3. Framework ? web2py, pyramid, django, web2app, jinja2 ? I need high
>>> productivity, efficient use of Datastore noSQL, MVC ?, templates,
>>> scaffolding, boilerplate code generation ...
>>>
>>
>> My bias here is for *lightweight* frameworks, of which Flask is the most
>> popular (webapp2, bottle and falcon are fine too) -- I devote an entire
>> chapter in the Nutshell 3rd ed to these four frameworks (templating, esp.
>> jinjia2 which works well with them all but especially Flask, is another
>> chapter -- no sense to have templating as PART of a framework, any more
>> than it would to have the kitchen sink in there, IMNSHO:-).
>>
>> I've wasted too much time in my life debugging boilerplate code resulting
>> from code generation: nowadays I insist on writing the code myself in the
>> first place (less likely to need debugging, and if it does at least I
>> should know why I coded the way I did, right?-). For Datastore access, I
>> use ndb (comes with App Engine Python, and was originally authored by Guido
>> van Rossum), not any framework that was designed to talk SQL and gets
>> shoehorned into NoSql willy-nilly:-)...
>>
>>
>>> I want to invest the time and effort to re-tool and up-skill, but as a
>>> *N*ewbie *S*eeking *A*dvice on Python Frameworks, I could use some
>>> solid advice from you.
>>>
>>
>> HTH!
>>
>> Alex
>>
>>
>>>
>>> Thx & BR.
>

Re: [google-appengine] Recommended configuration for a java based App Engine standard application?

[Þórir Gunnarsson]

Does anyone have any insights into endpoints v1 vs. endpoints v2? Any real 
life success stories perhaps?

We recently switched to endpoints v2 but without the endpoints management 
functionality, I'm hesitant to go all in if this isn't being used in 
production systems by at least a few people, or if it is not production 
ready in general.

ÞG


On Tuesday, April 4, 2017 at 4:42:25 PM UTC, Jeff Schnitzer wrote:
>
> You’re not crazy, I have also seen that problem. Use the com.google.appengine 
> maven plugin for the dev server for now. 
>
> I think this is the most relevant (albeit cryptic) issue that tracks that 
> particular problem: 
> https://github.com/GoogleCloudPlatform/app-maven-plugin/issues/158
>
> The com.google.tools plugin is the future, but the future isn’t quite here 
> yet :-(
>
> Jeff
>
> On Tue, Apr 4, 2017 at 6:49 AM, Þórir Gunnarsson <
> thorirgu...@goodlifeme.com > wrote:
>
>> I am currently using Maven and IntelliJ which in itself is fine. Most of 
>> my issues are with the Maven plugins and recently endpoints versions.
>> The com.google.cloud.tools plugin is not entirely there it seems, but in 
>> a lot of documentation from Google it is the go-to plugin.
>>
>> I tried to switch to the com.google.cloud.tools plugin the other day but 
>> ran into an issue with the local dev server (
>> https://issuetracker.google.com/u/1/issues/36589995) which prompted this 
>> thread here.
>>
>> ÞG
>>
>>
>> On Tuesday, April 4, 2017 at 1:24:52 PM UTC, Jeff Schnitzer wrote:
>>>
>>> Your path of least resistance is to use Maven (as opposed to Gradle or 
>>> Ant/Ivy). If you’re working in Java, you definitely want an IDE - Eclipse 
>>> and IntelliJ both have their following. I think most people will be happier 
>>> with IntelliJ but you have to pay for it.
>>>
>>> There are two viable maven plugins right now:
>>>
>>> com.google.appengine:appengine-maven-plugin is the older and more mature 
>>> plugin
>>> com.google.cloud.tools:appengine-maven-plugin is the newer and not yet 
>>> perfect plugin
>>>
>>> I would say we are on the cusp of the newer plugin being ready for 
>>> default use. It currently has trouble deploying the queue/cron configs, but 
>>> it looks like it’s getting fixed fast. I actually have both enabled in my 
>>> project right now.
>>>
>>> You also have the choice of “older vs newer” plugin for 
>>> Eclipse/IntelliJ. I would go with the newer one.
>>>
>>> Someone else will have to give you endpoints advice.
>>>
>>> Jeff
>>>
>>> On Tue, Apr 4, 2017 at 2:16 AM, Þórir Gunnarsson <
>>> thorirgu...@goodlifeme.com> wrote:
>>>
 Lately I have been getting some mixed signals about what should be the 
 configuration for a java based App Engine standard backend using 
 endpoints. 
 What I'm looking for is guidelines from Google or the group what would be 
 best practices. The recommended configuration should be production ready 
 and support local development and debugging.

 As I see it there are several options (please add if I'm missing some 
 options)
   - Environment
 - Maven
 - Eclipse
 - Maven project in Eclipse
 - Maven project in IntelliJ

   - Build plugin (assuming Maven is the way to go)
  - com.google.cloud.tools -> appengine-maven-plugin
  - com.google.appengine -> appengine-maven-plugin
  - com.google.appengine -> gcloud-maven-plugin

   - Endpoints
  - Endpoints v1
  - Endpoints v2

 Some reference material:
 https://cloud.google.com/appengine/docs/standard/java/

 https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java

 https://github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine/endpoints-frameworks-v2

 https://github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine/helloworld

 https://github.com/GoogleCloudPlatform/java-docs-samples/blob/master/appengine/helloworld-new-plugins

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Google App Engine" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to google-appengi...@googlegroups.com.
 To post to this group, send email to google-a...@googlegroups.com.
 Visit this group at https://groups.google.com/group/google-appengine.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/google-appengine/cd6225e2-e09b-454d-8ca3-c83faa4f377d%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email

Re: [google-appengine] Re: Google App Engine is slow to deploy, hangs on "Updating service [someproject]..."

[Stanislas Marion]

Hi Nick,
Thank you so much for your time and detailed explanations. I've been
investigating GKE and it seems like it strikes the right balance between
speed and convenience, so I'll probably move progressively towards it.
Best,

On Thu, Apr 6, 2017 at 1:28 AM 'Nick (Cloud Platform Support)' via Google
App Engine  wrote:

> Hey Stanislas,
>
> So, I can confirm that my prior investigation and intuitions were on the
> right track. I can confirm that a majority of deployment lag comes from
> programming the Google Cloud Load Balancers (GCLB). This is what we've seen
> in this case. Updates have to go out across the entire infrastructure while
> still respecting certain locks used to keep configurations consistent.
> These Load Balancers are not visible to users in the Console and not
> user-configurable as they're infrastructural and meant to be exactly as
> they are, else users may try to modify or accidentally delete them, which
> would cause a lot of issues.
>
> We're devoting a lot of energy to decreasing GCLB configuration push
> times, so rest assured that our efforts in that direction should pay off
> going forward.
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Tuesday, March 21, 2017 at 6:41:52 PM UTC-4, Stanislas Marion wrote:
>
> Great, thank you so much for your help, I'll be very interested in the
> details you'll get from your investigation.
>
> On Tue, Mar 21, 2017 at 9:22 PM 'Nick (Cloud Platform Support)' via Google
> App Engine  wrote:
>
> Hey Stanislas,
>
> The exact explanation speculated on in my last post shouldn't be taken as
> any description of what's necessarily going on, however it was an estimate
> of what might be happening based on the logs observed. I'm corresponding
> with experts in this area to get a more clear answer at the moment.
>
> You could look into deploying on Container Engine
> , which would mean that the
> front-end management done by the App Engine Flexible Environment
> infrastructure wouldn't be happening, rather it would be the responsibility
> of the resources you deploy on Container Engine (a managed service based
> pretty transparently on Kubernetes ). Surely
> deploying new container images to your pool of instances in a cluster (or
> multiple clusters) would be quite fast, since the master sitting in front
> of your clusters and the nodes in the cluster are not as massively
> distributed as the App Engine Flexible Environment serving infrastructure,
> hence updating their routing rules would be relatively fast. This is
> something to look into and experiment with if you don't want to wait on the
> more detailed word from experts, but don't rush to that if you're not all
> that curious.
>
> I'll get back to this thread with more details when they're forthcoming in
> our investigation.
>
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Tuesday, March 21, 2017 at 3:50:34 PM UTC-4, Stanislas Marion wrote:
>
> Hi Nick,
> Thanks a lot for the lengthy explanation.
> In this light, is there anything I can do to speed things up? Like for
> instance take care of the load-balancer myself? Indeed I don't see a reason
> why it should need to be changed. Could I do this with GAE or would I have
> to move to G Container/Compute E?
> Cheers,
>
> On Tue, Mar 21, 2017 at 8:42 PM 'Nick (Cloud Platform Support)' via Google
> App Engine  wrote:
>
> Hey Stanislas,
>
> My initial hunch was that the issue was the deployment of other resources
> necessary to support the containers running. My analysis of
> deployment-related logs appears to confirm this:
>
> I created a simple NodeJS app using your dockerfile and default.yaml. I
> then pushed the docker image to gcr.io and ran "gcloud app deploy
> --image-url ..."
>
> After about 1 minute of waiting, all resources associated with the
> deployment had apparently completed, but the command had not returned yet:
>
> ```
> $ gcloud deployment-manager resources list --deployment
> aef-default-20170321t185300
>
> NAME   TYPE
>   STATE  ERRORS  INTENT
> aef-default-20170321t185300-00 compute.beta.regionInstanceGroupManager
>  COMPLETED  []
> aef-default-20170321t185300-00ahs  compute.v1.httpsHealthCheck
>  COMPLETED  []
> aef-default-20170321t185300-00it   compute.v1.instanceTemplate
>  COMPLETED  []
> aef-default-20170321t185300-bs compute.v1.backendService
>  COMPLETED  []
> aef-default-20170321t185300-hcfw   compute.v1.firewall
>  COMPLETED  []
> aef-default-20170321t185300-hcscompute.v1.httpsHealthCheck
>  COMPLETED  []
> ```
>
> At around the same time that the last of the above completed, I see the
> following in the Console logs when selecting the "Deployment" logs source:
>
> ```
> {
>  protoPayload: {…}
>  insertId: "54B422B11D921.AE9070D.A80D9821"
>  resource: {
>   type: "deployment"
>   labels: {
>project_id: ""
>name: "-gclb"
>   }
>  }
>  timestamp: "2017-03-21T18:54:05.999Z"
>