carson

From hearing the details it seems that there is no real limitation to what you can execute as long as it runs on the instance. I get the feeling that if you zipped up all of the parts of python or ruby you need to ru you could execute a script using either of them as long as you initiated it from your node script. The key word here is probably "support" and that may be more of an issue if you want to edit your scripts with their web IDE.

Someone pull a CSI and enhance the reflection in the glasses at about 43 seconds in!

It would be awesome to see the 1st and 3rd tools open sourced.

Anyone know how "thousands of packages" cited in the original article turned into "millions of customers" in the gigaom piece?

It is also worth pointing out that you can fly to DC and NYC in under 2 hours from Louisville. You can fly to Chicago and get there before you took off thanks to the time change. So you have access to pretty much any of the "best" of those things listed here in about 3 hours including the time it takes you to drive to the airport, get through security and board.

#2 is possible but #3 isn't unless you have a completely open bucket and that wouldn't be good.

I will second this. At the bottom of this article there is a reference the article I wrote a while ago when Amazon released this feature. I was planing on doing multipart uploading at that time using the FileReader but there was a bug in the way S3 did CORS so I didn't want to continue until that was fixed. They fixed it and I never came back to it. Maybe be a good time to try it again. Resuming a partial upload seemed like a good win to me.

Can you share the empirical evidence that it works? There is a lot of talk about these programs but not many resources on the outcomes that I know of.

Maybe it depends on where you order from but I ordered one from element 14 a couple weeks ago and had it in 4 days.

This is great but sadly you can't resize images in the same version of mobile safari so it limits the usefulness for image uploads. There is a bug that makes large images incorrectly render to a canvas. It seems odd that this wasn't a use case they tested against.

There are probably any number of reasons, valid or not. The easiest to cite is "Who do I call if we have a problem with OpenJDK?"

Outside of OpenJDK there are other issues that make this a hard push for Enterprise customers. I haven't seen a large installation that uses memcached. Most go with something that is tailored for Java like Terracotta's bigmemory. Again it is "Who do we call if it breaks?"

Heroku is in an interesting place here I think. They are certainly on the right trail but this is VMWare's back yard now. Being a polyglot platform is probably a disadvantage for Heroku in this arena. If you look at VMWare they have a complete system tailored to work with Java. The hardest hurdle I see is that VMWare's solution can go from developer size deployments to production all on the hardware owned by the Enterprise. Heroku can't do that and I assume will never do that. Not "owning" the entire system will be an uphill battle for a lot of Enterprise customers.