7 ms·
Google App Engine PHP Runtime now available to everyone
- guidopallemans 13y agoWhat is it that Google has with Jetbrains? First they move their Android dev to intellij, now this...?
- gfosco 13y agoThey probably have a lot of respect for their tools. Jetbrains has some incredible products. WebStorm, PHPStorm, ReSharper, AppCode, etc. In this case, though, it looks like Jetbrains wrote a plug-in for PHPStorm, and Google is just mentioning it as a good method.
- yareally 13y agoI believe the Android team members at least have always favored Intellij based on the comments I've seen praising it in the Twitter Feeds prior to Android Studio's announcement and also that it's always been supported along side Eclipse as a way to easily import the AOSP source into an IDE (though only if you look in the source itself) if you choose to do so.
- ryan-allen 13y agoI wouldn't host anything of importance on GAE, since Google has this odd fascination with shuttering services with zero recourse for its user-base.
- jmillikin 13y agoWhich paid services have Google shut down?
- asdfologist 13y agoGoogle Checkout.
- prostoalex 13y agoGoogle Answers
- codonaut 13y agoThey do have a history of that, but AppEngine has a huge footprint right now, and Google is only expanding it's cloud platform with Compute Engine, redoing UI, etc. They're clearly investing a lot here, I don't think they'll close this as easily as Google Checkout or others
- ryan-allen 13y agoI supposed, but would you risk your business by locking yourself in to their platform?
- zafirk 13y agoPeter Magnusson from the App Engine team recently wrote about the lock-in argument: http://venturebeat.com/2013/07/25/google-app-engine-lock-in-what-lock-in/ http://venturebeat.com/2013/07/25/google-app-engine-lock-in-...
- j_s 13y agoI recently discovered this project as a replacement if you're using Java on App Engine: http://www.jboss.org/capedwarf http://www.jboss.org/capedwarf
- kodablah 13y agoThere is also https://github.com/AppScale/appscale https://github.com/AppScale/appscale
- benatkin 13y agoI thought Google Reader was too big to be shut down too. It had a small % of all users but a large % of power users.
- yeukhon 13y agoFree services are not guarnateed to remain open. Paid services can continue to live for a long time until market share shrinks so low. GAE can't. It has a deep root in the market.
- mountaineer 13y agoThat, or drastically changing it's pricing.
- jfoster 13y agoYes, or also not investing in it. GAE already feels like they're more interested in adding features that result in new customers over fixing bugs for the benefit of existing customers. Of the ~6000 defects ever opened for App Engine, ~1400 of them are still open. (issue tracker: https://code.google.com/p/googleappengine/issues/list https://code.google.com/p/googleappengine/issues/list)
- ajessup 13y agoHey folks - App Engine actually has an explicit deprecation policy spelled out to make sure this can't happen. See https://developers.google.com/appengine/terms https://developers.google.com/appengine/terms
- jcampbell1 13y agoIt clearly says they can do anything they want, but must give you 90 days of warning.
- benatkin 13y agoYeah, and in those 90 days if things break, they may not work as hard to get it back online, as they would have if there wasn't a deprecation.
- orf 13y agoThey would have to be suicidal to shutter appengine and only give 90 days notice. Won't happen.
- evan_ 13y ago"Suicidal"? Realistically what would happen, do you think? They shut down Google Reader, which is probably used by 1000+ times as many people. The average user of Google Apps Engine apps probably has no idea where the service is hosted and will never understand why they should blame downtime on Google.
- alanctgardner2 13y agoComparing this to Google Reader is ridiculous. Google Reader was free, and it had a small potential market. Even if Google Reader had 100% of the market (which I'm sure people will say it did), the number of potential users was not huge, and the amount of revenue they could bring in was pretty small. Even if App Engine isn't tremendously valuable now, it's a growth market, and easily monetizable. Google isn't going to burn a bunch of customers who could be - if they end up being the next Netflix - worth hundreds of thousands of dollars in recurring revenue. I wish people would stop with the hyperbolic Google Reader stuff. Google's bread and butter are web ads, and they're a shrinking market. As Facebook can attest, mobile is hard to monetize, and it makes a lot of sense to focus on areas where people can just pay you directly. AWS has already validated this market, Google has the capacity to deliver, they've just fumbled the execution wildly.
- elq 13y agoI'm under the impression that app engine is heavily used inside of google and its use is being evangelized. This leads me to believe that it won't be killed
- petersmagnusson 13y agoCorrect, heavily used internally. In fact I'll be talking about that at Cloud Connect in Chicago soon.
- petersmagnusson 13y agohonestly, i thought HN crowd was above continued "omg reader shut down google can pull the plug on anything". (a) App Engine specifically (and Google Cloud Platform in general) is being sold to enterprise as well, with SLA and deprecation policies. (b) App Engine has been around since 2008 and is growing VERY strongly. (c) Even if worst case happens, fine, move your app to somewhere else. Deprecation is officially a year, plenty of time to move. Any company can deprecate any products. GAE has huge usage (over 3 million applications), and we have two (and counting) compatibility partners (CapeDwarf and AppScale) that you can move. (d) GAE does not lock you in. Won't rehash arguments here, see: https://plus.sandbox.google.com/u/0/110401818717224273095/posts/Uoj3pmhbCkH https://plus.sandbox.google.com/u/0/110401818717224273095/po... cheers, P.
- saurik 13y agoThey've shut down much more than Reader (seriously, who said anything about Reader? was that even a service a developer could rely on?). Even APIs they don't shut down, such as their OpenID login stack, they routinely replace (dropping a lot of the maintenance and support, which leads to weird failures) with "exciting new APIs" that have no migration path, such as with G+ Login (I am thankfully safe from this issue, as I did something crazy with Portable Contacts that have me Google user IDs that I started storing before we even knew what they meant; so, to be clear: I have very little personal axe to grind on this, but others should be wary). They thankfully decided to just go commercial-ish with Translate, but the same can't be said about Charts (which had a long deprecation window and a replacement, but the replacement is a fundamentally different kind of API that has different browser requirements and even different charting capabilities). They also happily will just shut down things like Google Checkout and offer no replacement at all for key use cases like "sell a physical product" (if you sell digital goods, you might be able to switch to Google Wallet Objects, an "exciting new API" released a couple weeks before Checkout was deprecated). Google Checkout was certainly also targetted at enterprises, had a clear business model behind it, and had existed since 2006: everyone who built on that one (again, not me: I avoided Checkout like the plague) got only six months to migrate to a different provider (and figure out how they are going to handle any refund requests from recent customers, which will surely be horribly irritating as they won't be able to just tell Checkout to refund the transaction anymore). There is simply a patterned lack of care for people who may have built things on their stacks. (Yes, some services have deprecation policies, but let's not forget that those guarantees were themselves attempts to regain faith due to a previous round of services that had been axed with little warning ;P. After the anger died down from that they started reversing course, shortening or removing the policy entirely after the previous guarantees expire. I can only imagine the people who keep citing these deprecation policies don't have much memory of how this has all been going down over the past few years ;P.) http://googledevelopers.blogspot.com/2012/04/changes-to-deprecation-policies-and-api.html http://googledevelopers.blogspot.com/2012/04/changes-to-depr... Yes: you might be able to find alternatives to migrate towards... but if, by just acknowledging this pattern, you could avoid that bullet--which could easily come at the "least convenient moment" (such as when you now have some competition out of nowhere while attempting to launch a new product and raise finding), requiring you to suddenly drop everything for a couple weeks coming up with a new implementation of key infrastructure before the clock runs out--why wouldn't you?
- data_app 13y agoThat is the talking point of Google haters. Sounds like I am listening to Hannity on Hacker News.
- nacs 13y agoThis is probably going to sound a bit harsh but is adding general PHP support in 2013 newsworthy? Pretty much every 'cloud' provider has provided support for PHP for years now. Not only that but listing things like "ability to easily read and write files from PHP" and "support for [..] mbstring and mcrypt" as new features makes me less inclined to try App engine for any PHP work as it seems even the most basic things like writing files and mcrypt require App Engine-specific code. I'd much rather just deploy to Amazon's EC2/Rackspace/generic VPSs than have to add App engine specific changes to my code.
- dragonwriter 13y agoPaaS's are basically hosted specialized frameworks, and as such usually require framework-specific code. App Engine is Google's PaaS offering, and most of your issues seem to be "I don't want a PaaS, but prefer an IaaS or VPS". As Google has an IaaS offering (Compute Engine), it seems odd that, given those complaints, you'd compare their PaaS offering against other provider's IaaS offerings.
- fleitz 13y agoThe brilliance of PHP is drop files in folders, voila, website. As soon as you know the terms IaaS, VPS, and PaaS, you know too much to be using PHP.
- tlarkworthy 13y agoI use GAE with python a lot. But you can't find forum software not implemented in PHP. I wonder how easy it will be to rewire existing PHD apps for GAE? One serious issue is caching gets. Those rack up your bills in no time unless you memcache stuff. Interesting stuff though.
- ajessup 13y agoYou can use many forum products today if you use Cloud SQL as your storage service (and it's pretty cheap, it starts at ~$10/month). eg. phpBB - http://fredsa.allen-sauer.com/2013/07/standing-up-phpbb-instance-on-google.html http://fredsa.allen-sauer.com/2013/07/standing-up-phpbb-inst...
- tlarkworthy 13y agoyes that's exactly the kind of thing I have been looking for! Many thanks
- justinmk 13y ago> you can't find forum software not implemented in PHP Worth mention: http://www.discourse.org http://www.discourse.org
- jsnk 13y agoPlease work on supporting Ruby now.
- sebastianavina 13y agoand brainfuck
- neals 13y agoI would move my enterprise CRM package over to GAE as soon as this becomes a reality.
- pekk 13y agoBizarre that they would have gone for PHP before Ruby... Anyway, App Engine just jumped the shark, so Rubyists should know they don't need it
- dancecodes 13y agoI just saw some lines from GAE for PHP and saw very inconsistent and not quite code. All modules use require_once... well, well... And other many issues... But looks as massive code. Maybe translated automatic.
- mortehu 13y ago> All modules use require_once... well, well... Why on earth is that a problem?
- itafroma 13y agoIt's not necessarily a problem, but it's a smell. Modern object-oriented PHP development is done with autoloaders[1]: having to require_once every class file is unnecessary and brittle. It is odd that GAE doesn't provide its own autoloader for its provided classes, and I'd expect that to be addressed in the future. [1]: http://php.net/manual/en/language.oop5.autoload.php http://php.net/manual/en/language.oop5.autoload.php
- dancecodes 13y agoyes its smell
- dancecodes 13y agoyou mean spl_autoload http://us.php.net/manual/en/function.spl-autoload.php http://us.php.net/manual/en/function.spl-autoload.php
- dancecodes 13y agomore refine answer: just use spl_autoload_register
- dancecodes 13y agowithout autoload its seems useless and as monster. Its seems as broken by design.
- hardwaresofton 13y agolong live php!
- rjknight 13y agoI assumed from the title that this would be about Google open-sourcing their PHP runtime.
- neals 13y agoSometimes I worry. All this time I spent learning to maintain my own server, even though I am definitely a developer-first, is it wasted when PaaS are getting more common. Am I holding myself back by sticking to my own setup or am I keeping things cost- and performance efficient? Will this be an issue when I (finally) really need to scale up?
- prottmann 13y agoIf you scale up, you wish you didnt do the failure of running an own "cost- and performance efficient" solution. We did the same failure for many years. If you scale up, normally you did not have time to look for better solutions, because you need your time for your product and customers and not for your server. The problem is that you then loose customers or slow down the growth and that cost more then some bucks for a better cloud solution (and yes, cloud cost more).
- dancecodes 13y agoWhy you use multiple namespaces in single module? It is not good practise and smell. Official documentation don't recommend this.
- dancecodes 13y agowhy not use something base of PEAR coding standards ? public function foo($bar) { // //return (bool) $bar; // } This can help: http://www.gnu.org/software/emacs/ http://www.gnu.org/software/emacs/ http://pear.php.net/package/PHP_CodeSniffer/ http://pear.php.net/package/PHP_CodeSniffer/ and enable flymake php linting
- ScutSheng 13y agoI don't like google at all. Android is a rubbish OS
- smartmohi 13y agoHow to host PHP web application on GAE for free is explained in this tutorial. http://www.tinywall.info/2013/10/12/google-app-engine-php-windows-getting-started-hello-world-example-gae-development-deploy/ http://www.tinywall.info/2013/10/12/google-app-engine-php-wi...