Using the Dock connector involved paying Apple a licensing fee. This circumvents that, and it's similar (although more involved) to how Square's card readers work.
There is already an iOS serial cable though, which I would think would be a better option for many projects:
I'm all for new ideas and tools, but you have to bring something to the table other than just being different. And just being "smaller" is not enough.
This is the problem with Padrino- it isn't different enough. We don't need a smaller MVC Ruby framework, as there isn't much space between what Sinatra is great for and what Rails is great for.
There is also an assumption that scaling Sinatra up is a good idea. I'd propose that it's likely not.
As someone that has been writing production Rails and Sinatra apps for years, I have to recommend against using Padrino. Rails scales up and down pretty well, and I don't really see a need for Sinatra in anything but very small or single-purpose apps.
If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows.
I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different.
There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something.
It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails.
The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want.
The majority of developers will be more productive in Rails.
You will probably still have to look at the API docs (and read some source) from time to time, but the core team is taking documentation a lot more seriously now.
We're using SproutCore 1.6 and TemplateViews for a medium size app, and in many ways, it feels like the early days of any framework- there are a lot of nice features, but you have to be willing to dig into framework code and bend it to your will. SC 1.x has a lot of really great ideas, but they're buried deep in a huge system that is, in many ways, inflexible.
SC 2.0 seeks to change this, by making the framework much more modular (think Rails 3) and trying to do less. KVC/KVO really pay off on larger apps by allowing the data to drive the app instead of you having to write a lot of boilerplate code to push data and UI elements around as changes are made to the data. Statecharts are really useful for giving structure to a complex client-side codebase- I highly recommend using them.
I have only looked at Backbone briefly, so I can't comment on how it compares on a real app. But my gut is that it boils down to this: with Backbone you will be writing more framework-level and boilerplate code, which may seem more explicit, but will also be harder to maintain. With SproutCore, you will be relying on the framework to do more, but you will have to understand the framework in order to take advantage of what it offers you. And since SC 2 is still under heavy development, you should be OK with adapting to change as the framework matures.
The focus of SproutCore 2.0 is building views using Handlebars and the ability to use these views and the data layer in ways that play nicely other frameworks and web technologies. The only real demo so far is the todos app: https://github.com/sproutcore/todos
At the Chicago SproutCore Meetup, Tom Dale mentioned that they are working on a new UI toolkit to take the place of the one in SproutCore 1.x. There has been no word when that will be released, but I would expect a widget demo of some kind when it is.
The pie charts don't really make any sense. For example, a single project can use Cucumber, Capybara, and RSpec, or none of them, or any combination. But in the article and its graphs they are presented as mutually exclusive options.
Separating the results into exclusive types (testing framework, browser integration framework, assertion macros, etc) would make a lot more sense. Or asking what tool is being used for a particular task (unit testing, integration testing, mocking/stubbing, assertion macros, etc).
There is already an iOS serial cable though, which I would think would be a better option for many projects:
http://redpark.com/c2db9.html