 I'm going to welcome everybody to this week's OpenShift Commons briefing, and I'm really pleased to have John Frizel, who is the chief architect of Red Hat Mobile. If you may have known him in the past, the product formerly known as Feed Henry, which we renamed after being acquired by Red Hat a few short months ago, and it is now known as the Red Hat Mobile application platform, but John is still the same John, and he's going to give us a briefing on how to use OpenShift as your mobile backend, and I'll let John take it away from there. Thank you very much, Diane. So, good evening, good morning, good afternoon, wherever you are to everyone. As Diane said, my name is John Frizel. I came over to Red Hat as part of the Feed Henry acquisition back in October of last year and had been with Feed Henry since 2008, so have been working on mobile and with mobile for quite a while. What I'm going to do today, one slide only, and then straight into a demo, because there's nothing I love less than a really long side deck, so one slide is all it is. And then we're going to look at practical hands-on how to use OpenShift online as an embass for the Red Hat Mobile platform. One slide we have is just to give a bit of an overview of what the platform is, what it does, who it's for, and where does OpenShift fit in here. So basically, the Red Hat Mobile platform is a one-stop-shop, end-to-end solution for all mobility needs. So it's targeted at developers, service integrators, managers, line of business users, it has functionality for a wide range of user bases. It supports the development of mobile applications and web applications, so your standard web browser, mobile web, hybrid applications using Cordova and native applications for iOS Android, Windows Phone, as well as Xamarin and AppSeller Editor. You made a very conscious decision to make it a kind of a bring-your-own-toolkit approach. So while we do provide a graphical user interface that we'll be looking at in a few minutes, we also have a command line interface to allow developers to use the tools and the workflow that they're familiar with and integrate the platform very seamlessly into that flow. So the solution is divided really into two parts. You have what we call the core platform, which is where developers log in, create projects, build projects, and write server-side Node.js code. So our integration logic is all Node.js. If you're not familiar with Node or haven't heard of it, I strongly recommend checking it out. This gained a huge amount of popularity and is a very nice language. So core platform is where developers create, build, and deploy applications. And then where OpenShift fits in as a Paz is when we deploy those Node.js applications into OpenShift, we deploy them with a set of mobile-centric features that basically turns the Paz into an Mbass into a mobile backend as a service. So that's what we're going to be looking at today. We're going to be looking at how to sign up and actually get going with this and kick the tires, what functionality is available, how the integration with OpenShift works, and maybe a little bit of live coding depending on how this goes. So that's it for the slides. As I said, join us at commons.openshift.org and for a free account, we're going to head over to openshift.feedenry.com. Okay, so once you hit OpenShift.feedenry.com, you have the option to log in or request an invite. So if you have an existing OpenShift.com account, you just go to request an invite, fill in your details, agree to the terms and conditions, and sign up. So we send an email with an invite link that you can click through to and it will bring you back to the screen and allow you to log in. Just one note, we have a known issue where people with an OpenShift account that is not an email address are currently unable to sign in. That will be patched fixed in the next week. So if you are one of those people, bear with us and try again in the week. If your OpenShift account is set up with an email, then you're good to go. So once you log in, you will land on this dashboard. So you have a number of pieces of functionality available to you. You're getting started resources and documentation, tutorials and videos, projects, which is where mobile apps and Node.js cloud code is created, information on reporting and analytics, the ability to create Node.js microservices for integrating into backend systems, documentation on the APIs, administrative view, and some latest news. So let's start by having a look at some of the admin area. And let's look at what happens the first time someone signs in. So within the admin area, what we're going to look at here is embass targets and environments. So what we mean by embass targets is the place that your Node.js code is going to be staged to. And when you first logged in using your OpenShift credentials, we use those credentials to communicate with OpenShift and to set up what we call an embass target. So we communicated with OpenShift, basically logged in and set up some communications. So if we look across at OpenShift and at settings, we'll see what happened, and I've logged in several times here. We'll see what happened is that there was a RSA public private key pair created for secure communications, and there was an OAuth token created for API communications. So the keys allow us to push code into OpenShift on your behalf, and the authorization token allows us to make API calls. So this all happens seamlessly in the background as you log in. So once you're logged in, you're straight away good to go. One of the other things we can see here is we're told that we have a development and a production environment. So what this is giving us is a basic lifecycle management. Now it is possible to add additional environments. So if you were trying to enterprise life cycle, you may have development test QA pre-prod and prod as different environments. And you can then deploy your applications through those different environments, update them in different environments, and do continuous development without affecting your production applications. So your environments area here, we can see those environments. You have the option of creating new environments or enabling or disabling new environments. So let us now dig into projects. And we don't necessarily tend to talk immediately in terms of apps. We tend to talk in terms of mobility projects. And the reason for that is that typically the mobile app part of a solution is just one component of it. Granted, it's the most visible part. It's the bit that an end user has in their hand. But typically that application needs to talk to something, an Mbass, and then true that into backend systems. So we talk in terms of projects rather than applications because there's more than just a mobile app. When you land on projects here, you have the option of creating a new project. And we've populated this with a list of various different types of templates, web applications, core of applications, native applications, and various sample applications for data synchronization, push notifications, and various hybrid JavaScript frameworks like Backbone, Angular, and Ionic. So I created a project area on. So let's go in and take a look at it. So the project I have created here is, and we're going to be looking through the code in this application, it's a relatively simple barcode scanning application. So what it does is it integrates with a hosted service whose URL I forgot at the moment, we'll be able to find it in the code and allows you to scan barcodes and see details of other barcode searches people have recently been doing. So if we look through the various columns, we can see that we have mobile applications on this side. We have our Node.js cloud code. So this is our integration layer. It's effectively a microservice dedicated to the mobile applications. And over here, we have Mbass services that the cloud code will use to perform additional functions. Now, we don't currently have any servers added, but we are going to need a couple of services. So we'll add them as we go along. So looking at our client application, as soon as you click in, you land on a details page and we have details of the application. We have a git URL for cloning the source code and we have a preview of the application showing up in the preview over here. So as I said, the application allows you to scan a barcode or look at one of the recent searches. Now, this is live data coming from an external website. So as we click on each of these links, I have no idea what people have been searching for. So let's hope it's family-friendly. And RevLabs Muscle Rev Xtreme 60. Okay, not too bad. And that was an invalid barcode someone put in. Levi's Men's Belbran. Okay, we've seen some really, really odd stuff doing this demo before. So we're pretty good so far. Okay, so looking at some of the functionality we have here, we have documentation that can be used to provide people details about how the application works. So when you developer, for example, onboarding can get documentation on exactly how the application works. And for example, how to set it up. We have a live editor that allows you to make changes to files and so that should now be read out. Well, barcode scanner. And as we make changes here, our preview refreshes immediately and doesn't display what I just did. Oh, I love live demos. Moving swiftly on. We also have then then decide we have analytics. We have configuration options for your various mobile devices, for setting various options on the application. This is a Cordova application and you are free if you want to use a Cordova functionality for configuring any of these options. This is designed to allow people who may not be familiar with Cordova an easy way to configure the applications. You have integration with push notification. And then we also have the option of building the application. So this is actually a pretty cool feature. What it allows us to do is take the source code of the application, send it to a build farm that we host and it will give us back a binary. So in this OpenShift instance, we only have Android available as a build target. In the full enterprise offering, we support building for Android, iOS and Windows. So choose your platform, choose your branch or tag. We actually only have one branch here. Choose the type of build and this, if you were to do a release build here, you would need to provide credentials. Choose which cloud app you want. In this case, we only have one and you're good to go. We hit build and the platform is taking our source code, zipping it up, sending it across to the build farm where it will be wrapped in the necessary Cordova layer, put through the Android build tools and an APK will be returned. So if anyone has an Android device and a barcode scanner, get your scanners at the ready because we'll have a QR code in just a minute. While we're waiting for this because it may take a couple of minutes, let's have a look at what else we have down here. So we also have the option to export the source code. So this will generate the source code for the actual target device and allow you to export it and build it or run it locally. There's support for managing credential bundles here. So for example, with iOS, you need certificates, profiles and private keys and QR code. So I leave that up for a minute if anyone does want to scan it and play with the application. Again, not responsible for the recent searches. And credential bundles. So three, two, one, to scan. Hang on. Credential bundles allow you to manage to credentials associated with a build. So very often what you see is people will be doing ad hoc mobile app development. One developer will do a build for Android as a particular problem here because you can generate your own keys. So someone generates a key. It doesn't feel like it's an asset that has much value. They build the application, they put it in the store and then six months later, someone else is trying to update the application and if they don't have access to that key, they cannot update the app in the store. So we've seen it happen with customers time and again that they've lost the credentials and there is very little you can do. You can take the app down and publish one under a different ID but you cannot update it. So this gives you the facility to centrally manage the credentials for your applications so that you know exactly where they are and they're basically tied to the application. So that's a client application. The other type of application we have in the project here is our Node.js cloud application. So taking a look at this, we can see our application is running, which is good. It's currently deployed to our OpenShift target. We can see the URL here of the application within OpenShift. So if we were to open that URL, it just tells us that our app is running. If we knew the REST APIs to call, we could interface with them from the browser here and various other details, how to SSH into the application in OpenShift and your Git URL. Documentation becomes a little bit more interesting here. We've integrated with API Blueprint. So if you write your documentation and writing the documentation is as simple as editing the read me and the root of your repo. If you write the documentation using the API Blueprint syntax, when you go to the docs area here, it'll parse the API Blueprint and it will give you an interactive console for testing out the APIs. So this is really handy for, for example, mobile developers wanting to know what APIs are available for them to consume for their mobile application. So they can come in here, they can see the API, they can see the request response details and they can actually try out the API in real time. And we can see that we got a list of recent barcode searches back. So we're calling that slash barcode slash recent endpoint and getting a list of recent searches back. So this is communicating with the application as it is staged in OpenShift. Again, we have our editor. We can, if we were so inclined, edit code in a web IDE, which we're not really inclined to do, configuration of environment variables, the ability to browse any data that is stored in the hosted Mongo database, the ability to deploy the application. So if you've updated your code, you need to redeploy it back into OpenShift. It'll manage the pushing of the code and the updating in OpenShift. Live stats on what is happening in the application and what is happening in my screen. So not quite sure what that is. But basically stats on the various endpoints that have been called. Notifications on what has happened with our application. So when it's been deployed, when it's been stopped, started, if it crashed, you've all that information here, the option to configure alerts so that you get an email when a particular event occurs and a history of any alerts send out. We also have live logs of exactly what's happening in your application. So we can see log information here because we've been interacting with the application. So for example, the call to the recent endpoint. We didn't have any cache data. So we called out to get live barcode data. So that's pretty much it in terms of studio for the cloud app. So let us now take a look at services. So services are designed to be reusable, no JS components that you write once and then you consume them in multiple mobile projects. So in this instance, we have three services set up to support our application. We have the service that integrates with the barcode reader endpoint. And if we take a quick peek into code, we can see this is the website we're integrating with. So this is the website that we're calling. These are the recent searches and we're integrating with this actually in two ways. So for the read endpoint to get the list, sorry, for the recent endpoint to get the list of recent searches, they don't expose this as an API. So we're actually doing a little bit of screen scraping here and no JS is brilliant for this. So we basically request the webpage which is going to return this page here including our current searches. And then we use a little module called JS DOM. We load in jQuery so that we can use the jQuery goodness and we use jQuery to extract the information we want, stick it into an array and then return that information. So this service is wrapping up the fact that it's using search UPC and it's exposing a nice clean RESTful interface that can be called. If the search UPC page changed, if the IDs changed or how the page was structured, you make a simple change to the service here and anything consuming it continues to work as it was. Similarly for the read endpoint here, in this case we're actually interacting with the SOAP endpoint that they provide. We're calling this SOAP endpoint. We're getting the details of the products back as a CSV parsing them into JSON and returning that data. All in all, less than 100 lines of code and that's pretty ideal for one of these microservices. Small, clean, does one thing and does it well. So the other services that we have then, we have an image stream service that allows us to cache the images associated with a barcode lookup and a little dummy order service for a piece of demo functionality in the app that allows people to search for barcode and then order the item they found. In a real world scenario, this would be replaced with an integration into some backend order processing system. But in this case, we don't actually want to start ordering things. So we just have a relatively simple service setup. So back in our project, want services associated with our project. So we can now see a more complete view of the players in the project. So we have our client application on the left-hand side. We have our Node.js integration there in the middle and we have those Mbass microservices on the right-hand side that the cloud app is using to provide information to the client app. One or two other things to quickly touch on. We mentioned lifecycle management earlier on. We have the option of seeing exactly what has been deployed where and when. So in this instance, we've only deployed stuff to our development environment. But if we wanted to, we could promote either our client application or our Node.js cloud code into a production environment. Okay, so let's actually do a deploy here. So what this is going to do is take our Node.js code, package it up and send it via Git push to OpenShift. So we can see that the application has stopped here now and we can see live output of what's happening in OpenShift as the application has been deployed. So fingers crossed that this redeployed successfully because we kind of need this for the rest of our talk. Over in OpenShift, we can see our applications represented here as various apps. And if we take a look into one of them, we can see we have four cartridges. We have our Node.js cartridge and this is actually the one we're deploying at the moment. We can see that it's building. So we have a Node.js cartridge for running the developer code. We have a MongoDB cartridge for allowing persistent storage. We have a Redis cartridge for caching and we have this Feed Henry cartridge that's used to do back channel communications between the OpenShift application and the Feed Henry or Redam mobile platform. So it's this guy that is allowing us to view logs and view stats and get analytics data and things like that back out of the application in OpenShift. So from the Feed Henry platform, Redam mobile platform, I'm still not used to saying it, when you hit the deploy button, it will, if the gear doesn't already exist, it'll create the gear. It will provision the four cartridges and it will push today developers code into this one. So we can see that our deploy has completed now and we have the output of exactly what happened there. So we're good to go. Okay. So let's get out of the web UI because for most developers, you won't spend very long in here. You're gonna want to hack on your code and a web ID, it's not really a place to do it. So what we have is a command line interface similar to OSC called FHC. And this gives you a list of all of the various commands that FHC makes available to you. So some of the more common ones, FHC projects, and I'm not typing. FHC projects, we'll give you the same list of projects that we can see here, eventually. Eventually, eventually, or not. There we go. So we can see the same list of projects we have here. When you first download FHC and to download it, you do npm install minus gfhfhc and that will install the Feed Henry command line tool. It's a Node.js based application available if you want to look at the source code on our Feed Henry GitHub repo. Once you install it, you need to do FHC target to your OpenShift domain. So in my case, it will be jfrizzale.OpenShift.FeedHenry.com and then FHC login and using your credentials. I'm already logged in, so let's skip that step. As I said, we can do FHC projects. We can see our projects, take the project ID, we can do FHC apps, give it the project ID and it will give us a list of the applications associated with our project. So John, a quick question while you're doing it, someone asked is FHC is a gem like RHC? It's actually a Node application rather than a Ruby gem which is why when we go to install it, we're using npm. So npm is the Node package manager. So yeah, it's npm install. So for people who may not be familiar, npmjs.org is the home of all of the published Node modules, all 165,000 of them. And FHC is our command line interface here. Some documentation there, how to use it from the command line, how to use it as a module, how to extend it, basically everything you ever want to know about FHC. One of the other interesting things actually about FHC is because you can extend it, you can write some node code to require it as a module and extend it. It actually becomes very easy to integrate FHC into a continuous integration or continuous delivery process. So you could, for example, set up a job on your Jenkins server that uses FHC to access your domain in the platform and do nightly builds of your mobile applications or deploys of your Node.js code on a periodic basis or perhaps hook in a GitHub to trigger a build. So there's a lot of really, really cool integration options there with a pretty small amount of code for FHC. So one of the other things we can do is we can do a FHC projects loan. And let's take our project ID here. And this is basically a shortcut to save you having to go and get the URL of each application and clone it manually. So it just iterates over each app in the project and clones it for you. And that will likely take a couple of minutes. There we go. So we now have our applications cloned here. But we don't want to use them. Here's the mic cloned earlier. Okay, so if we go back into our project, we can see we have the same file system here as we have here. And we can go ahead and we can edit these files and commit them, push them back up. They'll be reflected here. They'll be, oh, it finally updated. They'll be reflected in the preview. But that's not a particularly nice cycle having to edit and then commit and push to see a preview. So what we'd much rather do is be able to do local development and see exactly what's happening in real time. And we can. So even though this is a mobile application, it's tooled up using a Node.js module called grunt. So for does not familiar grunt.js is basically a JavaScript task runner. So think make the Node.js JavaScript equivalent of make. So it defines its tasks using JSON and JavaScript. So first thing you need to do when you have cloned your application to do local development is you do an MPM install. And that will set up all your various dependencies. I had already done that. So super quick. And then you can, sorry, you can then do grunt. And it will start up your application. And if we look in the network tab, let's just refresh that. We can see the application started up. It made an initialization call back to the, back to the Red Hat mobile platform. And it was told your server side, Node.js code was running here. And then it proceeded to do a call to get recent scans. So once again, let's toy with danger and see what. Okay, family friendly. Okay, so we now have the application running locally in a web browser just running on local host set up by grunt. So our development approach becomes much easier and quicker then. So let's just move this guy over here. So I have Adam open here with the cloned directories. So for example, if we went into our index.html file and because I cloned this earlier, it still sells feed Henry. So if we were to change it to RH map for Red Hat mobile application and hit save, we get an immediate refresh. And we get that because in the background, grunt is watching for files to change. It sees our index.html has changed and it reloads. So we have a really quick develop test debug cycle going on here now for our client application. Similarly, if it was a native application, you open it up in Xcode, you open it up in Android tools and you do your development locally. So that's all well and good for the client application. But as we saw, this is talking back to a Node.js application running back up in OpenShift. So if we want to do local development of our server side code as well, we have a grunt serve that we can use here. So this will start up our application locally and we can then modify this and say grunt serve local. And this will tell the client application, don't go and talk to the remote Node.js code, come and talk to the local one. And we can see here on our console that as the app starts it up, bring up the instant trigger again, as the app starts it up, it made this call to recent. So it went to localhost, bam, bam, bam, bam, bam, bam, bam. Local OSAT has no one barcode recent. We can see it hitting here and we can see log input or log output coming out. It's telling us that it hadn't cached anything for the barcode search. So it called the service to do the search. When we reloaded, we can see now that it's returning cached data. So we look at the code in a minute, but basically it's caching the search for 10 seconds so that we're not hitting the search UPC endpoint every single time. So this is our server side code. And again, just as a very simple Node.js primer here, we're using a module called express as our REST API framework. Pretty much did a factor of standard, but there's express, there's happy and a couple of others, but express is the one we use. We're mounting some roots here. So we're saying that anything that comes in for slash barcode going to be handled by this file and the comes in for slash orders is going to be handled by this file. So we can see that our barcode logic here is, let's first check our cache. See if we have any recent searches. If we don't get any recent searches, we're going to call our barcode service. So that was one of the guys in the right hand column of this pre-column view here. So basically this guy is saying if I don't have anything in cache, I'll call it here. And when I get to response, it'll cache it. So the next time around, if it's within 10 seconds, it'll return from cache. Similarly, if you click on one of the barcode items, it's going to do a read. And we're doing a little bit more involved here. So we're calling again, if we don't have anything in the cache, we're calling the barcode service to its read endpoint. We're getting the data back and then we're stripping out information we don't need. And we're then checking to see if there is an image associated with the barcode. We're going to call our image service. And we're going to get that image back, base64 encoded and return it in the JSON object. So the mobile device is actually only making a single API call, and it gets everything it needs back, rather than calling the barcode service, getting a URL back, and then having to make a request to load that image. So that's actually a really important design consideration when talking about mobile. In terms of being aware of your payload size, number of requests, the fact that the mobile device may be on a lossy edge network. So using this Node.js layer here to kind of mash up and cache responses from multiple back ends and return just the data that the mobile app needs, makes for very, very efficient and really highly performing mobile applications. That's effectively what our barcode one is doing. Similarly, our orders one, it's a lot simpler. It's just proxying through to our order service. We can make a change to our logging, for example. That's like the recent old barcode recent. We save that again. The application restarts automatically, and we reload here, and we can see our log statement has updated. So once we're happy with what we've done, we can see where our modified files are. We can commit them, we can push them, and then either via the FHC command line, you can do an FHC upstage, which will cause the application to be deployed into OpenShift, or you can come back into your studio, and you can do the deploy through here. So that's pretty much all I wanted to cover. The kind of Highline takeaways are the application has been powered completely by OpenShift here. The Red Hat mobile platform is involved in the development and deployment cycle, but once the deployment happens and the application is built, all of the communications are happening against OpenShift online. Because we've deployed these extra cartridges, you get that kind of standard mobile backend functionality out of the box. So you get your storage, you get your caching, you get your analytics and stats and logs, and bundled in with your Node.js code. If we go back and have a quick look here, we have a set of APIs for the client application or your Node.js code to do all kinds of interesting things that you would like to do normally with mobile applications. So things like data synchronization for offline usage, authentication, security, push notification. All of this comes as standard in the Node modules that we bundle with the code due to deploy to OpenShift. So it basically turns the OpenShift pass there into a fully functional mobile backend as a service and the Red Hat mobile platform makes it really simple to create, build and deploy those applications and hope to move to your back ends. And I think that is about all I wanted to cover. We're at 44 minutes past the hour. So I think we will leave it there and hand back to Diane or open up for Q&A. Yes, well thank you very much, John. It's wonderful to see this. The last time I used this was probably a year and a half ago and there's some pretty wonderful improvements. Couple of questions have popped up and maybe you could explain what you're paying for when you're using Red Hat mobile platform. The gears on OpenShift online that you're using, there's a pre-tier, what are the costs involved for using, I'm gonna try and not say if you can reach me anytime, Red Hat mobile application platform. How do people get this? And besides signing up for you, is there any costs? Absolutely, zero costs to sign up on OpenShift.FeedHenry.com and this is something that was launched just as Red Hat Summit back in June. So this is a developer oriented open access free tier offering that uses OpenShift for their hosting of the Node.js code. So literally request an invite, you'll get an email with a link and you log in with your OpenShift online credentials and you have full access to everything that we looked at today. So if I wanted to run something in production that I've developed here, would I be using the OpenShift.url that you had? Typically not for a number of reasons. This is, it's effectively a community offering. It's designed to allow people to evaluate and kick to tires. So in the terms and conditions in the small print, we do pretty clearly state that this is not designed for running production applications. As I understand it, the free tier offering on OpenShift online comes with similar terms and conditions around running production applications. So if someone was looking to move from a kind of an evaluation into a production deployment scenario, that will be a commercial offering and that will be our sales team rubbing their hands and glee. Yes, well, we'd like to do that. Even if we're working on the community side, you'd like to have a enterprise folks do that once in a while. So I'm just looking at the other question, James, if you wanna unmute yourself, you can ask them yourself. Yeah, sure. I mean, I think you answered my question I had about the FHC app. It's a node package, not a gem like RHC. Another quick question I had was in regard to existing teams who are developing apps, you've got a process in place for developing the client side. Essentially, they just link up the Git repositories and use the API calls you provided. And that's it, is that correct? It looks pretty straightforward to persuade people to try this. Yes, it is as simple as that. So let me just reshare my screen here for a second. So when you're in projects, so if you had existing applications, your simplest approach here would be to say that you want to create a bare project. So my existing work, we'll call it. So it just creates a shell. There's no client applications, no cloud applications. Most people, if they have existing mobile stuff, are not going to have the Node.js layer. So you're likely going to want to create the Node.js application to integrate it by first. So we now have a project and we have some server side code in it. We can if we want to go ahead and deploy that to OpenShift. We leave that run in the background. And then you can import existing applications. So you're given an indication as to the type of app you're working with. So let's say it's a native Android application. System gives you some prerequisites. Still targeted against Eclipse. That will be updated shortly. Minimum OS version 2.3 has to have an Android manifest file. Next, app, next. And probably the handiest way you can either, if you already have the public repo, you can suck in your code from there. You can tear it up or you can set up a bare repo and then from scratch, get in it, get add, get commission or if you already have it in gate and you want to just push, you can add us as a remote and push the code up to the platform and then take advantage of the build farm and the hosting and the credential management and all the other stuff we looked at. Oh, that's really impressive. I spent all I can say in response to that. There's also quite a selection of documentation. So a raft of getting started material, overview, video guides, introductions, quite a lot of detail here on FHC to install it. One thing I actually skipped over if you're using FHC clone, you will have to set up SSH key pair. So within the settings area here in your SSH key management, you can just go ahead, add new key, copy and paste your public key and then you're hooked up for Git, polls and pushers and clones. So one of the other things that was really impressive back in the day, the last time I used it, was being able to write once and push to multiple platforms. And I know I did a demo or two of that back in the day from your web-based IDE. Sorry, when you say push to multiple platforms, are you talking? Build right at once and build it for Android or build it for iPhone if you had everything set up. And that was right. Yeah, so in the community offering, we only have Android as an available platform. If people want to build for iOS or Windows phone or any other device type or wearable or whatever, that is not available in the free tier. If I just hop across to one of the production areas, look at that, we have a barcode project here too. And in this one, we can see that there's a wider range of platforms, you have iOS, iPad, iPhone, Windows phone. So yeah, this is they, writing a hybrid app and then being able to do bills and target multiple platforms. So the functionality is still available, still exists, it's just not in the free tier community edition. Yeah, it's okay. As long as I know it's still there, I'm happy. If you send me a brand envelope with dollars or your alternate, I will give you an account here. Or just buy me beer. I think buying me beer is going to do it. James has got one other question, can the build process do store submission as well? No, it cannot. And that's something we've looked at quite a number of times in the past. And looked at would we, could we, should we automate that? And to be honest with you, the store submission is quite an involved process. There tends to be quite a lot of steps to it. And most of the pain of the store submission is deciding which screenshots you want, deciding what you're going to call the app, what the description is. It's a lot of process where it requires manual human input. So we could automate it. It is technically possible, but it would just be us building a UI that replicates what iOS or Android have, asking you for the same information in the same fields. So it would be of questionable value to automate the submission. One thing actually we do have on a similar vein. And again, it's not in the community edition. Again here. So here's an example one that has a number of different clients. So you might have native clients, Xamarin, web clients, and a raft of different services. We're not seeing the, here's screen, John. Oh, oh, oh, oh, sorry. Two seconds. We're working on visualizing. Okay, so sorry, what I was gonna say is I've logged into a different area now in one of the enterprise offerings. And if we go into the application here and we go to build, what we do have, which is probably of more use to enterprise, is integration to a range of mobile device management providers. So this will typically be for enterprise apps targeting employees, where the employee device, whether it's bring your own device or company provided is already registered with an MDM provider like AirWatch or MobileIron, or I know there are several others, good technologies, there's a range of different MDM providers. And we're working on integrations to the MDM providers to automate the pushing of the application into the MDM provider. Because we figured that that will be a far more benefit to enterprises than automating submission to the public app stores, which typically have a higher barrier to entry in terms of the information they require to deploy the application. So I think James, you've got James really excited here. He's asking, is the enterprise edition available now or soon? And basically the answer is yes. Yes, it's available now. It has been available under the Feed Henry banner for many, many years. And yes, it is available now and has been and will be. Yeah, and it works well with OpenShift Online today. So if you're interested in it, go for it. And one more question coming in from Ricardo Martinelli. Is it possible to create apps for? Yeah, sorry, I'm trying to read it. It's got a little apostrophe Android Wear, wearable apps. Yes, it is just not yet possible to build them automatically in the build studio or in the build firm. So we actually did this at the Red Hat Summit as part of the middleware keynote. The Red Hat mobile application platform was a big participant in that keynote. And one of the things we had was a small app on a Samsung wearable that interacted with the big screen for selecting items from a grid. So yes, it is possible. We have done it. It was good fun, actually. Yes, it was actually a really awesome demo at the Red Hat Summit. And I think there's a video link to it, too, which I'll share on the OpenShift Commons mailing list. Yeah, I'm pretty sure there is. And just one final thing, not to sound too much like Steve Jobs, but one more thing. With the embass targets, this is not just for OpenShift Online. So if you happen to have your own OpenShift 2, only two at the moment, but three will be coming. If you happen to have your own OpenShift 2 Enterprise instance, once you've set up your account, you can actually register your OpenShift Enterprise instance assuming it's publicly available on the internet, give it an ID, URL, a user account, kind of a service account for interacting with it. You register that and then you can associate your environments with that or maybe leave your development environment pointing at online and your production environment to point to your OpenShift Enterprise instance. Well, this has been pretty awesome. And then getting me to... I think I wrote a sample app about probably two years ago. I remember that. That, my little fun one. And that I was using to demo different platforms as a service offerings and using that and it was really cool then. It is amazing now. So I'm really thrilled to see it in its new incantation as a Red Hat product. If you are looking for more information, where should they go, John, to find your session? OpenShift.FeedHenry.com and that will give you everything you need to know. That's how you set up an account. And once you have an account and log in, you have a link to the documentation right there on the landing page. And that reading date, the documentation would keep people busy for a while. All right. If anyone does have any questions that can't find answers to on the documentation, you can find us on hashfeedhenry on FreeNode and we'd be happy to help you out there as well. All right. Why don't you put up your final slide and we'll thank you very much for being here today. I think that was all the questions we had and the recording will get posted shortly, probably tomorrow, on OpenShift Commons site, which is at commons.openshift.org slash briefing. So look forward to hearing more from you and hearing probably more about the road ahead with OpenShift 3. That's great to have this working and available now. So thank you. Absolutely. We'll come back and do another one when OpenShift 3 is available. Awesome. Take care all. Cool. Take care.