lucperkins

You're right that this is trade-off is somewhat inevitable, but I feel like Seattle's traffic is disproportionately bad for a city of its size. Seattle is consistently listed as one of the top 10 worst traffic cities in America and is not even in the top 20 in terms of population.

Seattlites also talk up their light rail line. Ummm, yeah. The first MAX line was built in 1986.

Ooooh, good call. Well, I couldn't include everything...

Yes. Yes, it is :)

Have a look at the article. Portland is consistently rated above Seattle according to all kinds of livability metrics. The public transportation is far better, it's more bike-accessible, there are more breweries and coffeeshops per capita, etc. Now, this is not to bash Seattle, which is unquestionably one of the best cities in America. But Portland's strengths outweigh Seattle's for broad swathes of people.

WONDERFUL list. You really nailed it all on the head, and I'm impressed that you really know the place after only a year. RESPECT.

Absolutely. Well said. I've never even owned an umbrella.

For those who suffer from S.A.D. (as I do), there are options: get a UV lamp. I also recommend acupuncture (how very PDX of me).

Yup. I'd add to that list, but it sounds like you're here already :)

Well, the (admittedly) crummy weather produces (a) solidarity, (b) a lot of good music, and (c) our healthy coffee obsession. So get over it.

I should also note that this summer has been absolutely magisterial.

In response to question 1: yes, it often very much is, as the examples that I raise in the article show. It could well be the case that there are better technologies for this kind of thing according to certain metrics, but those technologies don't have anything even remotely approaching the Node community driving them. In open source anything, that is decisive. Erlang is more mature, yes, but the community is small and highly insular. Tornado, Netty, etc. also do non-blocking I/O and the like, but they simply don't have the same inertia behind them. That inertia could be precisely what makes Node stable and acceptable for ever-broader enterprise usage. But overall, my claim is more sociological than technological.

Always feel free to use AppFog's live chat or send an e-mail to [email protected] and submit a support ticket. We're always more than happy to help!

Build packs and GitHub hooks are also on the roadmap

It's true! We're working very, very hard on Redis support. No ETA just yet, but there will surely be an announcement from us.

We worked hard on Sinatra support this past weekend. Give it another shot. I've deployed multiple test Sinatra apps painlessly today, which was admittedly far less painless last week.

We don't have an ETA just yet, but Perl support is definitely on the way!

The AppFog command line tool is very straightforward and even somewhat Git-like: http://docs.appfog.com/getting-started/af-cli. If the "af" gem is installed, "af push" is the equivalent to a "git push." You're right that it's not the same thing, but it's pretty handy.

Extra runtimes (newer versions of Erlang, plus Perl, Go, etc.) will become available over time. They're high priorities for our dev team, as are Redis, Memcached, etc.

What do you mean by "no custom app?"

I'm not much of a Java person myself, but our dev team has told me that the WAR + Tomcat route tends to work best on AppFog, at least at this point in time. This is also our recommended way of running other JVM-based languages.

Hetzner is simply not a platform-as-a-service. It might be a good deal for a server, but that's not what you're paying for with a PaaS like AppFog. What you're paying for is application lifecycle management, from deployment to scaling to cloning to re-deployment on a different infrastructure, to adding services (like Mongo, MySQL, etc.) at the click of a button.

Serverraum alleine = etwas ganz ganz ganz anderes.

AppFog has "real" support (including live chat with all plans, including free plans). And the business model will prove to be quite sustainable (and bundled with a readily comprehensible pricing model).