 Okay, so today we're going to talk to you about building mobile apps with Roads. And these are, unlike the previous sessions, these are native mobile apps, not mobile web apps. So Roads is the local source framework that allows you to build native mobile apps for all shipping smart phones, iPhone, Windows Mobile, Blackberry, Symbian, and Android. Right into code one time and at a very high level. So briefly on a rollable mission. Our mission is to allow you to mobilize applications very geographically with a great user experience. We want to provide the high level productivity and portability of web programming, but still provide the device optimization and offline capability of native mobile apps. So I actually like the fact that we followed Brandon Lynn's presentation from intraday because that's how, you know, if you want to write a mobile web app, it's a great way to do it. If you want to write a native mobile app, that's what we're all about, native mobile apps. But we're still letting you do the sort of web programming experience. Now, something that I typically have to clarify is, OK, well, we're going to let you write your app in mostly HTML. Oh, wait a minute, that's a web app. No, no, no, no, it's all down. Native mobile apps, which means taking advantage of device capabilities, camera, N, SMS, GPS, and also allowing you to work with data offline. And of course it's all open source for rapid adoption by developers. One reason is graphic adoption, but the other thing that's going to sort of pleasant surprise is we've actually got a lot of user contributions to our stuff. And I think that's going to become more and more important over time. So background is the stuff that you guys already know. Smartphone sales are exploding under 5 meters smartphone operating systems, but the difficulty as a developer is what are you targeting? Smartphone, because the growth leaders, iPhone and Android, are the install based lighters. This is especially true for enterprise apps, right? So within the enterprise, and the iPhone is a big device, I love my iPhone, but within the enterprise, it tends to have much smaller footprint. So the other thing is, and with apologies to Brendan, I really like those guys, and we've actually talked in treaty about providing services around roads, and I think they're incredibly well qualified to do that. And we don't do this at home all over the world. We're just totally focused on building our framework that will never provide services. We're getting a lot of demand for it. Those of you that are interested in doing that, yes, they have a thing in one of our developers, this is that I call the Roads developer network. It's just about providing referrals to developers like you that refuse our platform. So with the emergence of the iPhone app store, native apps are pretty much one-to-day. So users want to use apps that run locally on their device, and certainly for things that in enterprise apps and areas where you're changing data. So part of my background is I used to manage engineering for the server and our browser, a good technology. We had the first ad-executive browser, and it was called Good Access, now it was called, I don't even know what you're calling it now, but it was called Good Access. And we had 8,000 companies using it. But here's the thing, when we actually went out to these companies and we wanted to have examples of them interacting and creating transactional data, plenty of them used it to read stuff. We couldn't find one out of 8,000 companies that they actually had people changing data by the browser. So that, combined with the fact that at Good we had 200 engineers working on just email and browser on just 3 OSs, made me realize that there has to be a better way, there needs to be some kind of platform. Because we really had a really good product, I think, for Windows Mobile and Tom and Symbian, we really never quite got there. And we had people requesting us to do it for other OSs, and we just said, are you kidding? We can't even do it for you. So that was sort of my formative experience of why we started Rumble was so that you could have a way and you could write an app once and it runs everywhere. And also that it really is about native apps. So what we built is a framework called Rose. It allows you to build the framework quickly, build the app quickly in HTML and Ruby. And why I was saying HTML and Ruby? It's an empty model view controller framework, very similar to REST. We love REST and talk about it. We have the sync server that I have never written this to the code for. And that's already in REST. I love REST, but REST is between one and two orders of magnitude too big if you're on the device. So what Rose is, sort of a bad time on Roses like Rails, but it grows more places. So it has a lot of comment with Rails, but it has, for example, a very lightweight forum instead of active revenue. And it has a very lightweight... Everything we've done is very, very, very small. The challenge I set for the team was the whole framework, plus the user's app, has to stay within three minutes. Which of these devices and smart phones is sort of pretty small. And it actually exceeded that. I don't know if anybody read the artist technical article, but the editor, I was very impressed by this, he went and wrote his own Windows Mobile app. I said, why do you use Windows Mobile? He says, I know you guys are focusing on the iPhone. I wanted to do it on another device. So he wrote his own Windows Mobile app in the executable source, 2.3.90. So it works with sync local data, it exploits device capabilities, GPS, N-data, camera, SMS. And it's all available open source at github.com. And when I say that it's built open source, it's real-time. So I don't know if any of you have ever participated in our Google group or something or not, but because we have a bunch of our engineers in Russia, we're sort of like the sun never sleeps on the Google development team. So the experience we've had so far is that people file stuff to the Google group and then there's a check-in within 24 hours. And we get part of that before we're not doing the thing where we say, oh, we're open source when we drop a snapshot every six months. You know, it's all real-time. So one of the mobile components, one is ROSE. It's a micro framework for building locally-executing, natively-optimized mobile apps. You've got an app generator, just like the Rails scaffolding generator, very similar. For your objects and interests, you mostly edit HTML templates. So the developers that have used our stuff, it's certainly great that you can change the controller and write it in Ruby if you need to. And people will do one or two things, but generally developers are spending most of their time just editing HTML templates. I'll show you that in a minute. It also happens to contain the first mobile Ruby implementation. And in a Ruby group, hopefully that's something that you guys are excited about and I don't want to diminish that excitement, but people will sometimes say, oh, does that mean you're the mobile Ruby company? And they say, oh, I'm glad that you're excited about it, but not really. We actually have good fans of Ruby, and we believe that eventually there'll be rubies on all the devices just shipping. And that's a very, very good thing. It will certainly decrease our development cost. And we're actually meeting, I'm speaking at Mubuco in Barcelona next month, and meeting with Thomas at that because he thinks it's cool that there's this mobile Ruby. And what we're going to try to do is get our mobile rubies on his code pack. And so then we really won't be a mobile Ruby company. It will be all about this framework, right? The ability to write in-apps and HTML, and having this like sync client and the device capability and not so much the fact that we created this Ruby implementation. And that said, the team has done an awesome job. We actually made it work really fast by doing some of the techniques done by Enterprise Rails for the write back fashion with PC Malik was done. So we did that too. We had a huge difference in the execution speed on mobile. We've done quite a few tricks. So I'm really proud of the engineering for what they've done, but still we'll probably get away from always maintaining that implementation. So that's Rows, and that's what runs on the device. And then we have another piece called Rowsync, because we say we're all about sync offline data, right? So we have to give you some way of doing that. And having the poor device talking to your back end is not a really good thing. It's not what you want to do. If it's talking to your back end and so for rest, it's going to be very expensive. It's a lot of stuff for the device to manage. So the model of Rows is there's a Rowsync client embedded in Rows, and what it does is it's sort of managing for you, getting all the data from the back end, bringing it to your device, taking any changes you do on the device and sending it to the back end. So it's all transparent to you. So you as developers are always working with local data. You just use your ORM, it's a simple sort of subset of active record-like thing. And the data is always local, so you're never worrying about it. You're dealing with the network or any of that stuff. And then the idea is that Rowsync client talks to the Rowsync server very efficiently basically through this optimized based on format. So this is the architecture that we're referring to. So we provide everything that's there in red. Ruby, I love this part. The Ruby interpreter, the ORM, which we call ROM, the web server and the Rowsync client. So the question is, why is there a web server? We're all about the native local stuff. Why does it need to put a web server down here on this device? Optimization. Well, so it turns out we do it because we're letting regular views in HTML, right? So we want to use, and you can see that third-party components are just great things, we have browser control there. So that's how we let you write reviews in HTML and we use the embedded browser control of whatever device it is to do the rendering, which solves so many things for us of making it look good on all the devices. Things, it's part of the magic of why it just works. You know, you write it once and you just do build for the other device and it just works. But that browser control expects to talk to a web server. So this web server we wrote is very small and it's just sufficient to pull that browser control into thinking it's talking to a web server because, again, it's all about working offline, you know, sync data, locally, offline. So, who cares about our internals? It doesn't matter as much, right? But what are you writing? So you're writing, everything is there in gold. And so there's an app generator that generates a set of, every often thing you care about, say, I don't know, you're doing a CRM app and you care about accounts and employees and opportunities and contacts. So you'll run the model generator for those things and for each model, you'll get a controller and you'll get an HTML template. And again, you shouldn't need a modifying controller. It does what you, like, what happens when you generate it from real scaffolding. It's got basic 3D, 3DSD, delete operations. And for most of the stuff you need to do, you generally don't need a modifying controller. But you will probably end up modifying the HTML template. So we give you something basic, sort of like real scaffolding, but you'll end up modifying that. Now, notice what we have here on the server. You don't have to, sometimes people say, well, do I have to do SyncD? You don't have to. We certainly highly recommend it and for most enterprise apps, you'll almost certainly want to do it. You'll almost certainly, we do have some consumer apps that are out there that can give demos up later that they just don't need SyncD. They can do cool stuff with device capabilities and they don't need it. So you don't have to write that. But if you're doing, like, some interaction with some back-end app, some enterprise app, or some SaaS app, up there in the service, you're going to want to write a source adapter. We'll generate a source adapter, a skeleton, and that source adapter is basically six methods. Login, query, create, update, delete, and a lot more. That's it. So we generate the skeleton, you put some code in there, and typically, you'll very often just be putting, like, a line of code in each one. At least for Sugar CRM, it's very straightforward. You're dealing with some nasty, gnarly back-end that has some bad, you know, interface exposed. You know, there will be a few more lines, but it's very approachable writing those source adapters. So we provide some samples. We have a sample app for Sugar CRM. We have a sample app for Siebelfield Service. We get some requests to extend it to all of Siebel's CRM, and so we'll do that. But more and more, it's about third-party apps. So there's a third-party app for Basecamp, you know, the original Rails app, right, you know, DHHs, one flop. So there's that company called Pariser Data, it had a product called Trailguide. It was written for Windows Mobile, and they approached us because they wanted to port it to everything that they didn't want to go, or small ISV, they did not have the resources to go right at the iPhone app, and the BlackBerry app, and the Android app, and the Symbian app. So they wrote it for us. That product is called Trailguide from the VDG group. We run our visits off of it. You know, it's just great, great capability, and they're going to put other load tracking, I think like us as well. That's load tracking backend, but they're going to put other load tracking backend, like track and JIRA, behind that as well. There's a product, so Wikipedia, I can't take that one, a camel thing, great guy, saw the stuff, and really inside, and he was most of the way through writing an iPhone app. The longer story is, they bought, he had an iPhone app, the original Wikipedia iPhone app, Wikipedia bought his app from him and said, but maybe they're all the chance we want you to make. So we rewrote it. They've got 90% of the way of rewriting it, you know, they have to see for the iPhone, and he saw our stuff, he said to his bosses that Wikipedia, Wikipedia, this is a better way because they wanted Android, they wanted other OSs, and so he rewrote it and wrote it, and the interesting thing about that is, the reason I'm telling you that you had written it once in the other way, is he cut down his code base by 80%. So it was one-fifth the size of the code base once he did that. And we have this actually very detailed spreadsheet that shows like, you know, each class of thing, whether it's HTML or JavaScript or like just what you were able to save when rewrote it. There's another app called Pixelpedias, an equal consumer app thing where, it's not written by Wikipedia, that you take a picture and then it says, okay, where are you located? And then it finds a map, right, using the GPS, and then it looks up where you are on Wikipedia, because Wikipedia lets you give it a GPS coordinates. So if you use Pixelpedia, and I took a picture here and say, which I will do, after this session, because it'll say, okay, you know, here's the map, and you are the Marconian part of the model. I would assume that would be a lot of Wikipedia. So another exciting thing is, BMC, we've asked me before that, is BMC? So I think they're the fourth or fifth Microsoft in the world, somewhere, certainly in the top 10. A product called Remedy, that's in 10,000 companies, it's a, it's a IT helpdesk thing, and they are writing their next generation. They have a existing mobile product that's focused on the IT helpdesk professional. They're extending that to be something that all users can use. They're anticipating a much greater sales of it, and they're writing that in the roads now for release in August. So, a lot of high-level overview, build a voice app, get your data. Generally, it's better to start with growth sync. That's what we do in our tutorial. If you're writing something that you don't care about sync data, then you can skip that step. But generally, it's a little easier to do it that way. Generate your app with growth sync, it's a timeline thing. Then develop your app and your Ruby HTML as your choice. I will text me. I'm just going to call out to you guys too, and then you build your app. So let's go ahead and do that. So, here, and what I'm going to do is, in each step, I'm going to show you how you can sort of tell what Rogan can do. The first step that I've already done this here is to say gen install rows. So, for a gen, it's another reward like any other gen. And so, once you do that, you get this utility called Rogan. So we're going to say Rogan, and we'll see the different options that we have. Is that big enough? Should I control public? A little bigger. Okay. So, you have 20 main things you can do. You can generate an app, a model, or a source. So, typically, you're going to start you're going to generate an app, and you're going to generate a bunch of models. And you can generate a source if you want to do the same. And the interest in time is to be half hour free to take one. I'm just going to generate an app with one model. So, I'm going to say Rogan app, and then it would give us the usage for that. And it says, okay, actually, that one's pretty simple. It's just the name of the app. So, I'm going to say, Rogan app, and I'm going to say, it's a little contact matter. It doesn't generate too much files, just like you're used to. I'm proceeding into that directory for a model. What it wants you to do is generate all of the options. It wants you to give it a name. It's a Rogan model. Contact. Once a source URL, we're not going to do the same thing right now. We can do it offline later. I'm just going to give it a blank source URL. A source ID is going to be anything. I'm going to give it an ID of one. And then we'll give it a set of attributes. It will say name, phone, city, and now it generates all the stuff in the model. It should seem very familiar to those of you who are Rails developers because it's the same very simple set of stuff. You generate Rails, similar controller, similar set of files. Here's our contact directory. It should seem very familiar. You shouldn't have to modify it with your basic crud. One of the things that's interesting is that all these get-and-post things, they look really similar to Rails, but they're not quite identical to Rails. Anybody guess why? Brendan. When you look across all these browsers, some of them are a little bit punky in terms of supporting like good, delete, post in standard way. So you may be as close to the Rails REST conventions as we could, but it's not identical. This is another part that you typically use. Again, it's the edit form. You may edit the new form, but the thing I wanted to show you is this HTML is very generic, right? It's just in tags and in tags. And some of you might say, well, aren't you doing any style elements or anything in CSS? So here's what we do. We give you a generic. We generate generic stuff. And of course you can style whatever you want. Add your CSS style in library. And that style in library varies per device OS. So on iPhone, can you guess what we're using as REST style in library? We used IU Live into a Q&A. It's now on Facebook, but it's this great thing that makes your, so our iPhone apps look like made of iPhone apps because of the work that, mostly the work we did. We took it a little bit further than what we did, but we need to drop down less and get out of the way. So it looks like made of app because of that IU Live approach. And so we embed that. That shows up in the project where all the CSSes are there. You can change that just like we enhanced. Go do stuff, you can change that. And it'll just change, you don't have to go check it in to roads, right? It'll just create your app tree that you're going to build from. So you can change it I'm sure you guys could potentially improve it. Although we've got to be that good the iPhone apps look really good. We've done the same thing on Windows Mobile and RIM on Blackbird. And they look pretty good. I'd say that the iPhone UI is like maybe an A because we've spent a lot of time on it. The RIM and Windows Mobile are like D pluses and full disclosure, the Symbian and Android are pretty clean so you get all the device capabilities, you get single local data. I'm not ready to pretend that like our Symbian UI looks like a native Symbian app. It looks like mostly like a web app. But we've actually had we have developers that are interested in contributing to the Symbian style of the library and I'm sure we'll do better talking with you. Developers in Europe tend to really know that stuff. And Android was just released last week at March 24th at the open source business conference and that's it's pretty basic right now. It works but it's pretty clean. So let's go ahead and I'm not going to change anything of those now. This is the top page of our app. This is the Index VRV that's right in the in the root of the app and we can add like images and fonts and whatever we want to do probably do a lot of branding. Here I'm just going to do something very simple. I'm just going to have a link to my contact object. Now this is where by the way if we have multiple objects we have a whole bunch of things right contacts, employees, opportunities like all the things that we might care about say in our CRM or whatever app that we're working on. So we're going to say and now I'm ready to do build. So I love the fact that this is a real conference sometimes I've done presentations also where I'm showing this and they're like what's great. So we have this e-list and we have this is actually with 1.0 you see all the OSes I just had a little version on this. So you see build scripts for Blackberry iPhone and Windows Mobile then the rake device slot is just a build but when you say rake run it doesn't build and launches the emulator for that particular backend. So that's sort of cool. So I'm going to do a rake run iPhone app. That would not happen if my emulator wasn't. So this is our new app and I'll go ahead and do a rake and it shows up in the list and so we get a basic run of those objects. We could continue and like do more generation of objects and change our top level stuff and we'll continue to get that that app built. Okay so the status we did a 1.0 release this is actually my green presentation at the open source business conference last week March 24th at the open source a little bit earlier than that but at the open source business conference in the big we called it the 1.0 release and we did that because we now support all business marketing lessons once we added Android and it also has camera support and we got I don't know if any of you saw but we got a fair amount of questions like CMAT, R's technical venture the info world sort of surprised me how much our reaction we got from that. So two other things that I wanted to tell you guys about one is ROHA so this is something we're about to release and what it is is it's hosted mobile app development very similar to how many people have used ROHA here so very similar to the idea of ROHA so we are not doing this as a way to we're not a cloud play we're just doing this as a way to be great if I can use it even easier like maybe I don't want to install my own copy of ROHA saying have an easy way to expose the app maybe I don't want to install the built environments for the different even though we give you these great scripts we expect you to have like the iPhone SDK installed or the Blackberry SDK etc. so what we do is we provide hosted app development hosted build so you don't need to install all the different development kits and for some of them like Symbian and Blackberry if anybody's ever done that it's pretty challenging to get all that stuff installed we make it easy with these great scripts but you still have to get those installed hosted provisioning so this is the idea that you will have like mole m.my company.com and the user hits that with their web browser and then we figure out what version of the app you want and we deliver that you don't have a link to that download hosted runtime so we actually have a copy of Rowsync so you'll notice if you install Rowsync that it's got a lot of features to be multi-tenant to allow different people to hit it you might say why does that even matter like if I'm just installing my own copy of Rowsync it probably doesn't but it was all so that it could be the back end for this row hub thing and in the first hundred registrants we probably have to up that we've got over 200 we want people to try it but they're interested so we'll expose it in ways sorry sorry 201 oh okay so the other thing I wanted to tell you about it's not in the slides that we're doing an announcement press release tomorrow is there's a mobile app development contest to be it's first exposed like in London have to go we're really into promoting this all and so if we're pushing back the deadline based on feedback from the user pushing back the deadline to May 24 and we'll judge it by the end of May and so what this is is right now in Rowsync if you're willing to open source your app if you're not that's fine that means you end up getting our commercial license and that's all good but if you're willing to open source your app then one of the things because we're if you're really open source your app then you can participate in the contest and the best app that is created by May 24 we have a $10,000 first prize and we have a whole bunch of smart phones and related accessories for at least the next 10 best apps so we have a reasonable chance of getting some cool swag out of it a lot of really cool stuff out there I don't know if anybody's seen my photo in London he's writing a mobile twitter app with our stuff and he's not just blogging about it he's established an entire blog it's called rubyonmobile.wordpress.com and it's far better than our I mean it's way longer than our tutorial because it's multiple blog posts and I don't think we could have gotten away with that long it's a great resource to learn about our stuff and so his twitter app is going to be good because he's like doing all this mine but he's using all the native device capabilities which a lot of the other like mobile twitter are not because it's just hard our stuff it's just tags and it's very easy so that's an example of one one app out there but it would be great you're all you know accomplished for a reason it would be great to have some of you guys spend for the contest as well I believe that the declarative tag based approach i.e. web programming should be a hard sell for Rails developers it's just more productive then write in tons of deficit code and Java code and C-Sharp code and you know Cindy and C++ code we think that a rich client against local data is much better than remote web apps smart phones I know it seems hard to believe we're always sort of to minimize the wealth but please get it to try and joke it for yourself and it's open source from the ground up for services or any of the things that other open source companies try to make money with it's pure dual licensing and what that says is if you open source your app then it's free the fast one I totally get it it's fine Wikipedia is open sourcing their stuff it is it's up on github now and that might end up being the only actual open source most people want a commercial license so we offer a commercial license as well to ISVs it's 5% of your revenue how do we make revenue if you sell for 20 bucks in the app store we won't put out or if it's up front we use however you make your money we want to share your success in a small way so it's 5% for ISVs and we have another license that's an enterprise license that's per user per year so the reason why is enterprises in terms of their users are not going to be absolutely going to have some money I was wondering about it so it's interesting it's a little small so when Hampton Catlin first started using our stuff he didn't even say can you please support Hamlin so I proactively told him I said you know what I love Hamlin and things that are like that I like Markerby and other things that aren't ERV but it turns out ERV is the smallest thing so that's fine I agree we wouldn't eliminate it from consideration because it turns out it was sort of sort of okay on the space but that was the original rationale now remember you can add whatever you want and we have instructions on the Wiki about how to do that so if there are some in the library that isn't there you can add it you can't do that if you have to give back the money the Apple do you have to sell it at 5% no no if you sell the Apple in 20 bucks and Apple gives you 14 right then we only want 70 cents so it's whatever you're getting do you have to refund the money back to the customer oh yeah you know what that's actually a good point so we did recently modify our ISV agreement because we had an ISV that raised that variation so the new ISV agreement has tests or like how do I do GDV so I'm putting more of my time actually programming in Rails because I've maintained a posting and I am in Roast I'm jealous of the people who get to spend all the time in Roast but Rails has obviously a great testing environment and the ability of our spec test is wonderful we do not have that in 1.0 in Roast nothing close to that but it's that means we're going to do the full compliance tests for our Ruby so sometimes people say sometimes we support and the fact is we don't have great documentation so we're going to test our Ruby we're going to do performance testing but we're also going to provide Rails with great testing and framework for their apps so mission on scripting with the application so it turns out that Rule332 code over the internet to your interpreter it's very clear that there's hundreds of apps that have interpreters available that tell them that client has a chef in it there are apps that use the embedded JavaScript so Ruby is just one of the many interpreters that are out there so the violation is that you download the code and execute on your Ruby interpreter so that said protect developers from being violating like unknowing accidentally making some Ruby call and downloading so we've taken out need-out you know we have a framework so the idea is you're sort of like working within the framework anyway and you probably don't want need to need to need out if you're sort of working within the framework so to protect developers that aren't that like twice what we say you're compliant with rule 3.3.2 as long as you're not downloading code and we'll try to make it very difficult for you to do that like that that roads basically can control the yeah we give you not to say not only do we do camera capture but we do camera capture sync to the back end so there's features in roads and we'll make it very easy for you to get those pictures to your back end app and this is based upon feedback from developers is that is that is that mechanism sort of like OpenGL or something like that yeah so you can extend roads to do additional things we have a developer in Egypt named the Shunivertel and he is we get an instruction that says he is doing a feature of overriding the incoming because we just said you know we'll eventually get to all the device capabilities that's like real low on the list so we actually have instructions on how you can modify roads and add additional capabilities and like Shunivertel assigned a contribution agreement and you know we'll take his stuff back into the framework so it'd be great if you wanted to add stuff and we'd love to have your contributions back to the framework okay thanks very much