1. We are here a Future Ruby with Adam Blum. So why don't you tell us a little bit about yourself?
Thanks Werner. I am with Rhomobile, I started Rhomobile last year, with a bunch of talented engineering co-founders, and our goal is to provide a framework that enables people to very quickly build smart phone applications that are native mobile device applications, let them write their app once and then they run as native apps across all smart phones. I have done other mobile start-ups in the past including Good Technology where we had a very large team of engineers trying to write email on a web browser across just three devices. And we had very large team of engineers, around two hundred, and as it became clear that there were going to be more smart phone OSes not less, now there are six major smart phones operating systems it was pretty clear that if you wanted to do anything that was less horizontal than email, then you needed to have some kind of platform or framework to enable that to be done. So that was really a lot of our motivation in starting Rhomobile and we are really pleased with how quickly it has been taking of and started to get used by developers including the ones here at Future Ruby.
Yes, Rhodes is a model view controller framework very similar to other model view controller frameworks like Rails or Python Django or Java Struts, in fact what Ruby on Rails is to websites, Rhodes is to building native smart phone applications. So absolutely the controllers that you write with Rhodes will be done in Ruby, the views will be done in HTML templates and we chose that not because you are building mobile browser applications, in fact if anything it's sort of a anti mobile browser approach it's all about native apps, but HTML is something that everybody knows. So, you write your views in HTML templates, and then combine with your controller, and then we have a very lightweight ORM, called Rhom that is your model so you take your Rhom models and your Ruby based controllers, and your views and you compile it all into native executables for each of the OSes.
3. Which OS do you support at the moment?
We support all the major smart phone operating systems, iPhone obviously, Windows Mobile, Blackberry, Symbian and Android.
That's a good question. We have two major code lines, our C based Ruby, shared a lot of code, and that is 1.9 based, and so that obviously applies for Symbian for Windows mobile and for IPhone. And so they share the majority of the code. It's absolutely a mobile optimized Ruby, it's stripped down, it uses a number of techniques like TCMalloc to make the memory operations faster, definitely wasn't a myopic port. The Java based Rubys are based on X Ruby not on JRuby, JRuby would be far too big, so they are based on X Ruby and then it's in fact our own Ruby in there. As I mentioned yesterday at FutureRuby, however, at some point it's probably worthwhile to factor out the Ruby out of Rhodes and get that out into the community and have the rest of the community help us maintain those ports and I have talked with Matz about that at EuRuKo. It will be a good thing for the whole Ruby community to do. Factor out just the Ruby piece.
5. Factor out not just the XRuby but all of the Rubys?
Remember the Rubys for Android and Blackberry which are Java based, yes they started with XRuby which is in effect a discontinued effort, just because it was smaller. At this point, essentially it is our Ruby, it started with XRuby but it's our Ruby that is there. And in the long term it makes sense to peel out the Ruby from the rest of Rhodes and get that out and have it be maintained by the community which is maybe a way to bring up that we see the value of what we do as more the framework so Rhodes with all the things that it brings along, the model view, controller framework, the ORM, we have a sync client that is on there, we exposed all these various device capabilities as both Ruby libraries and as tags, and that is the real IP. If device OS vendors started shipping their own Ruby, that is a good thing for us, if we peel out these Rubys and get them out to the community so that we have the community helping us that would be a good thing as well.
You write, as we describe, your controllers in Ruby, and you are going to be making library calls to the various device capabilities that are exposed there, GPS, PIM, Contacts, push capabilities, and camera support etc. Then you have your external templates that you do your user interfaces with and when you are done then you run a build task that's a rake task like any other build task in a Ruby environment. And you will build a native executable for each different device OS, one of the key differentiators of a Rhodes built app versus a whole earlier generation of mobile technologies going back more like eight years ago if you were to do this, the typical approach was people would have their own non HTML based but sort of proprietary ways of defining apps, they would have an interpreter that was on the phone, some kind of runner.
And what they would do is define their app, the user would download the interpreter on the phone and then they would be able to download these application abstractions. So pretty much all of the people that were in "enterprise mobility" that started six-seven years ago, that is what they would have, that was the right thing to do at the time. In 2009, number one that approach which absolutely made sense for devices with limited CPU and memory is completely unnecessary in the world of modern smart phones. And number two: it's no longer acceptable so the app store has made it very clear that that will not fly. And those expectations have bled over from the app store to other device OSes and the users of really all those device OSes people want native apps, and native executables, they are not going to download some kind of intermediate interpreter runner and then download apps for it. So that has pretty much vanished from the smart phones, so it's a good question what do you end up with when you do a build you end up with a native IPhone apps, your .cab files for Window Mobile, your cad files for Blackberry, .sis files for Symbian and your .apk files for Android.
And then you just do what you would normally do to load apps on the phone. One is obviously if you want to get to the app store then you submit your app to the app store in other cases you could take those native executables and put them up on your website, and then we also have a hosted development as a service, where we actually offer a vending machine or visioning machine so that once you have done your builds, you want to give out the URL to people we'll provide that as well.
7. What ends up in the executable files? You ship Ruby with that?
Correct, this gets back to in the days of modern smart phones what makes sense to have on the device. Our framework, once you have built the native executable nobody knows that you have used the framework. Now the price that you pay for that is of course you have all the great bits that we have like the Ruby and the ORM and the sync client get embedded in very app. But the whole size of it is around 2MB. In fact that is what our budget we say 2MB or less, the 2MB is a non issue these days on 16 GB iPhones and you may have a few less GB on other phones but you can assume whatever modern smart phone you have, you will have the ability to have thousands of apps that are based upon Rhodes. The old approach would say "Well if I have got all this infrastructure I should have that one time and then just download these apps", which we could have done, if it was necessary. Just isn't necessary because these smart phones are just really first class computing devices now.
8. So the Rubys you provide, do you omit any library features from them? Do you cut them down in size?
We absolutely do. We see the Ruby as in service to the framework. So we have this Rhodes framework and there are a lot of things that you shouldn't need to do if you are using the framework. Couple of other things is that we pre-compile the Ruby classes so we are actually generating Ruby 1.9 bytecode, that is both for speed and also for ensuring that the app does what it has been compiled to do and what it's been tested to do. And for the same reason so that it is acceptable to modern app stores so that they know that it does what it's said it's going to do. And we also do things like remove the eval capability because we don't want to give programmers the rope to hang themselves with; we want them to be able to very easily build a compliant app so as a result we never had an app turned down on the app store.
9. Your Java based Ruby not to call it XRuby, is that compatible with 1.9?
No, it's 1.8 based, there would be a development effort to updating that so all this stuff about doing compiled bytecode only applies to the C based Rubys but it seams it was critical for doing things like iPhone in the app store that we deliver this pre-compiled again both for speed and to ensure that the app does what it says it's going to do and no more. There is just work that needs to be done to get the Java based Ruby up to 1.9 and in fact there would be one motivation to factor that stuff out and get it out to the community, we prefer to just have a Ruby to use rather than necessarily maintaining that Ruby forever.
10. So this Java based Ruby basically runs on J2ME devices?
Theoretically it could, it runs on Blackberry which we see it's not actually quite J2ME it's really its own thing. Theoretically somebody could port it to J2ME devices. It may be something that if we factored out the Java based Ruby maybe somebody else could do that port, to take it to true J2ME. We are very focused on smart phones we will not do feature phone ports. However our stuff is open source, and we have had people not just express interest in moving the Ruby to feature phones but also moving Rhodes itself to feature phones potentially to LiMo it could be interesting, it's just we won't port to LiMo until there is a LiMo device that has a keyboard on it.
Yes. It's a Linux based mobile platform and right now it's pretty much feature phone oriented and if that changes, then we'll consider doing the port but it would be great if somebody in the community wanted to do the port of Rhodes to LiMo ahead of them.
12. So if I go to the iTunes store, the app store, which apps would I find that are Rhodes based?
There is a bunch of them out there, we can't really tell which ones, we just happen to know anecdotally from a bunch of developers there is an app called ...Pedia that is out there, there is an app called "Issues to go" that is out there, there is an app for Siebel called Rhosiebel [spelling unclear] that is out there, there is an app called "All my means" that is out there, but there is dozens of apps that we don't even know about, because we are GPL if people GPL their app we say you don't have to execute a license with us and we know that is being done a lot, we have got thousand helpers on our public beta, on our Rhohub, and we know they are doing things, we have the right to go see what they are doing, but in general we don't mess with people's privacy there unless they want to invite us to look at their app. And then we have hundred of developers on our forums so my guess is the way that we know about something being in the app stores is because somebody has said: "Hey check out this thing on the app store and download it".
13. You mentioned Rhohub. What is that?
Rhohub is our hosted development as a service, as far as we know it's the first development as a service for mobile and what that lets you do is do all of your development in Rhodes online. So you get, I used to say a hosted editor, but it's really a hosted IDE so it avoids us having to write our own IDE. What it lets you do is generate, if you use the command line tools in Rhodes you have an app generator which will generate a base level controller in HTML templates then you can then edit, and then we have the sync server we haven't talked much about yet that helps you get access to enterprise apps called RhoSync but if you use the command line tools you would do separate generations for Rhodes and for the RhoSync we have a generator for the backend source adaptors.
If you use it on Rhohub it's a way to bind together these things, you basically define your app and then you define your objects that are interesting in your app. And the attribute on those objects will generate the controller, the HTML templates, and the RhoSync source adaptors on the backend. And then we have the hosted IDE and then when you are done with editing then you will do a build like we talked about with Rhodes but now you can do your build online. Sometimes the builds can be time consuming you don't have to wait for the builds on your device, and you don't have to install all the underlying SDKs on the device.
So if you install Rhodes offline on your own machine, we'll do builds for you with rake but you still have to have the SDKs installed you have to have the iPhone SDK installed or the Android SDK installed you don't have to actually use those IDEs or their build script, you can use ours that runs on top of those, with rake but once you do it on Rhohub you can have Rhohub do all the builds for you. That is development time and then at runtime we also do hosted runtime. So people would say: "What do you mean hosted runtime?" It's a native app, it's not a mobile web app, what is that even mean to have hosted runtime?
That is really two things today but it can be more things: one is the hosted provisioning or the vending machine so like when you do the builds we know where your builds are located and we can give you a mobile.yourcompany.com and then users hit that with their browser, mobile.yourcompany.com, and then we detect on Rhohub what device they are running from and we will serve up the appropriate executable so it's a vending machine, as one thing. And then the second thing is a hosted sync server. So we think our sync server is pretty easy to install but for some people keeping a server up and running getting an URL for it and keeping it up and running and making sure that it is sized appropriately can be real work. So we give you that hosted sync server. And we had some requests from beta users of Rhohub of additional services to make it easier for them to develop apps.
One of them is a mobile advertising service and one of them is mobile analytics. We are going to be very cautious about introducing new services, because we don't want to introduce services that could just as easily be provided by third parties that are already out there, trying to serve that business, so we will see if there really are needs for these services, it's all intended to be an accelerant to them building Rhodes based apps. If there are needs for other services that make it easy to build apps then we will introduce those as well.
Every Rhodes app includes this RhoSync client. You don't have to use it, you can write a RhoSync app that either it's completely local or does all of its connections to the Internet either through JavaScript because you can put JavaScript in your HTML templates or through sockets in Ruby. However we think it's generally not the best way, we think the best mobile experience is you sync the data from wherever your backend is we have the information down to the device and then you have that information whether you are online or offline. To make this easier to do we have the RhoSync client embedded in Rhodes and we have a RhoSync server and that RhoSync server turns out like a Rails app just like any other Rails app.
But we also have installed programs that you say "I want to install RhoSync" and we install everything we install the Ruby, the Ruby on Rails, the database, MySql whatever you need to run and so RhoSync is your server and all that RhoSync needs in order to keep data from a backend current with what you have on your device is using what we would call a source adaptor. A source adaptor has six methods: login, query, create, update, delete and logout. You write those six methods in Ruby I assume a lot of people watching this are Ruby developers, so you can imagine that compared to the old way that source adaptors were written for other sync servers if you write it in Ruby you can do a lot in very little.
These source adaptors tend to be like a page or less of code. We ship with a number of source adaptors as examples for like Sugar CRM or Siebel and other enterprise apps. And actually you can get a lot value by just writing a one method 'query'. You write a handful of lines of code that might call your REST backend, in our online tutorial we call it a Rails based REST backend actually you don't know that it's a Rails based REST backend but you call a REST interface and it's like four lines of code, to call out grab the stuff and then you are actually calling the REST interface calling back JSON which gets parsed into a hash of hashes and then as long as you have a hash of hashes then it gets automatically pulled into this server cache in effect and then it's the job of that server and the RhoSync client that is on your device to keep that all up to date.
You as a developer in your Rhodes app you don't know anything about how this thing happens all that you do in your Rhodes app is you assume that the data is current and so you are writing basic ORM code just like you would in Rails with ActiveRecord where you are referring to the objects and their attributes. The original purpose of RhoSync was to partially do sync data but also to give the user that experience that their data was always current and available to them. The side benefit as turned out is that it's created a really great easy programming model. Because now when you write Rhodes apps your data is just there.
You refer to objects and you generally shouldn't have to be doing any network programming, no Net::HTTP calls or pulling data over the wire in XML, your Rhodes app can just assume that the data is always there.
15. How do you handle conflict resolution with RhoSync sync capabilities?
Ok, that is a great question. What we do is we actually have a spec for how the internal of the Rhosyn algorithm works on the wiki, so anybody can see what is there, obviously it's open source so you can see that as well. On every source, so an app can typically consist of a number of sources. So maybe your accounts, and contacts and leads and opportunities. So you have a source adaptor for each one of those. Every source, and you can set it on a source by source basis, has an option that says allow conflicts or not. If you allow conflicts, then what happens is and that is the default by the way and basically last in wins, but we still flag the fact in the log that there was somebody that came in and updated the records so let's give an example. You have an account and you update their zip code.
And you have an account and you update the phone number. Now it turns out that because we have in our sync protocol we chose to do this object-attribute-value both wire format and storage mechanism, we can handle that fact and say "That is not conflicting". And we will do both changes. Part of it is this whole object value approach that we do also known as a property bag approach, for a wire format, so that handles the vast majority of conflicts.
Now, if you both do change the same thing, you update the zip code and you update the zip code, if we say allow conflict then you'll win and your zip code update will be second but we will flag that in the log. If you say don't allow conflicts, then yours goes in and because no subsequent query has happened, there has been no subsequent sync, of downloading the data, then it's about apply your update that says "Conflicts are not allowed" and it won't do the update and it will also flag it actually in a very similar way in what we call the source log. You were bringing up the question about these other sync servers that have been out there, in general like many Rails apps and frameworks, we are all about the 80/20 deliver 80% of the value with 20% of the complexity.
We think that the choice of attribute object value civilization approach eliminates the vast majority of these conflict issues, and we have this simple thing of allow conflicts or don't allow conflicts provide a nice high level log that developers can use and then developers can use that log to do whatever interesting business logic they want around it. In terms of doing, you are correct that there are other sync servers that have done much more complex things, many more options for dealing with this, and that is something that we would want to see either come from developers themselves, within their apps and just give them the right hooks, or from the community.
16. What is the future of Rhomobile and all your offerings starting from Future Ruby in the future?
I think that is a good question because lot of people say "Rhodes is done so what else do you need to do?" One of the things that we want to make sure we will do a good job of and it's sort of a new category so we are not really comfortable putting dates around is Rhohub, this development of this service. Right now we are thinking that it will launch mid August but it's really going to launch when developers tell us it's ready. And we also don't even think we necessarily know every service they need to be successful.
So a lot of it it's going to be about making Rhohub successful and then really beyond that for sorts of core Rhodes and what the capabilities are, we are very much driven we think we have delivered the base offering that people can do useful things with, and as far as incremental capabilities we will just listen to our customers and very extremely responsive to the list that they say they want.
17. Finally what does the name Rhodes mean? Where does it come from?
Most of our company and product names are bad puns on things. So Rhodes is sort of a bad misspelled pun on Rhodes is like Rails but it goes more places.