Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Google App Engine: Google's monthly $322.50 gift to you (stringbuffer.com)
53 points by edw519 on May 3, 2009 | hide | past | favorite | 21 comments


Kind of surprising that Google is lowering the quotas. This seems like bad judgment that could anger a lot of account holders who will move from non-paying to paying.

It would have been much better to start out with low quotas and gradually raise them. What other freemium services have lowered the value of their free service? I can't think of a single one.

Imagine Gmail doing something similar and reducing their storage quota. It's unthinkable.


I agree. Taking it initially from 100GB to 10GB now in May to 1GB is extremely limiting. In fact I was building a service on there but moving it based on this.

The economics have changed drastically and really don't even compete with a basic shared hosting account.

1GB per day and 6.5 CPU hours for free is nothing much really. There are plenty of other cloud providers now that can compete on price.

One huge advantage to GAE was the free quota which was a huge draw. The limiting architecture and broken platforms were ok to deal with at that. But why not just build on EC2, Media Temple gs, Mosso, Joyent or some other now where you can install almost anything you need as well as having the scalability?

Very bad move by Google to reverse this drastically on the free quota which is only now just a gimmick.


"But why not just build on EC2, Media Temple gs, Mosso, Joyent.."

It's already been pointed out many times before that EC2 != App Engine unless you plan on building your own heroku, RightScale, or scalable system. The price on those scalable services isn't base EC2 or VPS pricing either.

Included with the price of App Engine services is the outsourcing of server instance management, datastore management, etc.


Agreed. I realize AppEngine != EC2. Amazon is more a set of components, EC2 being one that you are right you have to setup the systems to scale yourself. In actuality, you will probably need EC2, SimpleDB, S3 etc.

I was trying to make the point that it makes Google AppEngine much less of an advantage over other services in the market even ones you mention which provide these managed components (many times without the restrictions of GAE, I am a big fan of GAE and a little irked at the pricing). Media Temple gs has some of what you mention.

But I believe a large reason people were even considering using Google is the great startup potential to scale up and get lots for free at the beginning. No startup can run with 1GB per day on a single digg, reddit, slashdotting at all without paying. It gave about 3-6 months of runway before for growth now it isn't really even a month of free for a reasonably known application or content.


They just upped their Google Checkout credit card processing rates as well. They used to be 2% + $0.20 which was phenomenal, but they've increased them to a tiered pricing that isn't as competitive for smaller merchants.

I wonder if Google is realizing they can't offer such great deals anymore. Are they losing too much money with those platforms?


It's not really a gift. They are plenty companies out there providing free service with some limitations just like GAE. It's called marketing.

I wouldn't deploy anything on GAE as long as Google is the only provider.


The domain name is plenty visible in the (brackets) on the right of the title... why include it again in the title?


he probably uses a shortcut to speed up submission process, and the domain name is in the page title.

javascript:window.location=%22http://news.ycombinator.com/submitlink?u=%22+encodeURICompon...


To remove formatting, indent 4 spaces:

    javascript:window.location=%22http://news.ycombinator.com/submitlink?u=%22+encodeURIComponent(document.location)+%22&t=%22+encodeURIComponent(document.title)


And to annoy everyone, add a really long non-wrapping line to throw of the formatting of the whole page.

Add some spaces in there, till it fits on one 1024 screen.


To be fair, this is really a problem which should be fixed server-side. Happens all the time and it's really annoying.

Long strings in a "code" box should either be broken up programatically (spaces inserted slashdot-style?) or put in a div with a scrollbar.


overflow:hidden or overflow:scroll on the element or containing div would fix it.


It's there, it stopped working in Firefox 3.


If anyone can tell me what to put in the html to fix the problem, I'd gladly do it.

Why did this stop working in Firefox 3?


You can put white-space: pre-wrap; in the css for the pre tag.

You can also add overflow: auto; instead of hidden, but you'll need to add width tags going all the way up to the width="85%".

Note: I tried mucking with the HTML and adding the widths, but can't quite get it to work. But overflow does not work without a defined width, and width does not work unless the parent has a width.

You might need to add:

  html, body { width: 100%; }
Relative widths with overflow are annoying to get right.


The simplest thing would be to insert WBR tags every so often. Could be a small performance hit, so I'd do it on write. In Ruby, this would be:

content.gsub(/\S{40}/, '\0<wbr>')


Xichekolas' Greasemonkey script fixes it for me in Firefox. Maybe you could include the cross-browser equivalent of his Javascript snippet? (http://userscripts.org/scripts/review/25039)


Since the code in my GM script has become a bit ugly, here is the relevant portion (cleaned up and commented):

  // Get all the pre tags within comments.
  var xpathpres = document.evaluate("//span[@class='comment']//pre", document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);

  // Iterate through them.
  for (var n = 0; n < xpathpres.snapshotLength; n++) {
    var thispre = xpathpres.snapshotItem(n);

    // Find width of the spacer image, add 120 (found experimentally).
    var reduction = (thispre.parentNode.parentNode.parentNode.firstChild.firstChild.width || 0) + 120;
    //               pre     span       td         tr         td         img

    // Get the size of the browser window, default to 800px.
    var winsize = window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth || 800;

    // Ensure a minimum width so things don't disappear.
    var width = Math.max(winsize - reduction, 300);

    // Set the width.
    thispre.style.maxWidth = width + 'px';
  }
Really seems like there should be a pure CSS solution to this though. As others have pointed out, setting overflow-x: scroll and then defining widths for all the containing elements explicitly would probably fix it without depending on javascript.

If he were to use my solution, at least he would know the spacer image width serverside, so wouldn't need javascript to find that. Would still have to use it to find the window size though.


Change the comment span to a div and add an style="overflow:scroll;" or add it to the .comment style. overflow:scroll doesn't work well on spans.

Or put a div inside the comment span containing the comment content with the same attribute, overflow:scroll then it will have a horizontal scroll on that item not the page.

However this might want to be tested as you may need some min and max settings so that long vertical comments don't scroll. Probably not a quick fix the way things are setup.


You will also need to add width tags climbing up the tree to make overflow work. Width: 100% on the tables, tr, and td's (possibly not all of them, I didn't test it fully.)

(And you can't put pre in a span, so change the span to a div like drawkbox said.)

But use overflow: auto not overflow: scroll.

And if you are worried about vertical scroll use x-overflow: auto (doesn't work in opera though).


Do really exists any Java App Engine -based web out there? I'd love to have a look.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: