That's a cool idea. If you combined it with a Coin style card that allowed you to switch cards on the fly you could not worry about blowing your budget.

It costs? For what?!

Congrats guys. How about tht international[1] now please. :)

[1] https://github.com/balanced/balanced-api/issues/23

Seems like great timing with the ember conversation on the front page too. Isn't ember a offshoot of backbone?

No. Ember is a fork (conceptually, at least; I'm not sure about common code) of SproutCore: http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor...

Ember was Amber for about 2 days but changed due to a naming collision with another project. I really read too much Hacker News.

Any light on how to pull back once a change has been deployed? If it's version controlled you can check out a previous version but do you automate tht?

Hi there. I'm the author of this post.

We use git, so it's easy to revert commits, or push an update with '-f' that resets to an earlier version. Once we push this new commit (that simply puts us back to an earlier state) to our release branch, it's picked up by the testing system just like any other commit and pushed out.

That seems like a slow process if you're "oh shit, rollback, rollback, rollback!"

If we're already at the "Oh shit" stage, then we might be happy sacrificing test coverage to go back to known-good code, in which case we would run our fabric `deploy` task and have our rollback completed in ~30 seconds. The idea behind this process is that we never have "oh shit" moments like that :)

(Please see my other response to a similar question, as well)

Is there a timeline on this wait list?

This assumes traditional engineering == big teams

That wasn't the assumption I went into the talk with at all. In fact, our team was quite small when we saw problems from traditional horizontal or vertical engineering org structures.

I've created dozens of sites and never really noticed any CSS performance issues.

I have got orders of magnitude faster sites by combining CSS or js files, gzipping content, adding cache control headers, serving via a cdn and not serving code that's not used.

I've also really benefitted from using logical markup and CSS selectors, not those designed for "efficiency" of the computer rendering them.

If you are done with the obvious optimizations, at some point you spend half a day to gain 50 ms on the backend. And that's a good day. If you are able to achieve 25 ms on the frontend in half an hour, it's worth considering. E.g. Font Awesome [1] is very popular, but the selector performance is horrible.

[1] http://fortawesome.github.com/Font-Awesome/

The new homepage you dudes have is a big improvement. Why haven't you blogged about how you're previewing this stuff on GitHub? It's fun to watch a start up growing and changing there and I think it it's in really well with the MVP/agile mindset

It is great indeed. The only think that is not so cool for me is that the font rendering of 'Fanwood Text' is pretty bad on Win 7 Chrome 25.0.1364.97. But I love it. Just wish the font had a better rendering.

Thanks for the feedback, we're *nix shop so I only tested it in browser shots to be honest (shame on me).

I'll fire up a VM, check it out and try to find a good fallback or alternative for Windows.

Thanks! We're hoping to blog about this soon. In the meantime, here's the github thread in which we discussed our new homepage design: https://github.com/balanced/balanced-api/issues/264

This is very cool. I'm not a ruby dev but just coming into this thread and finding out there are alternatives for my languages is fantastic.

Congrats on a cool product and I'm glad it was posted here.