 I live in Sydney, where Christmas is in June. I work for a company called Ninefold, where we do all sorts of some stuff with the rents deployment. And I work actually in this thing. This is a Christmas from the next week. And right here, I have my sandwich this morning. So I'm a web developer, right? I've been doing this for a number of years and I got used to certain things. And I like how it works in there. When I saw first time web, it kind of made it with my sense. You have elements like buttons. You have ends. You have functions and you connect them. And it's pretty simple. You can just get going pretty quickly. But what actually makes it so good is the zipper of concerns. Say they treat every screen pretty much as a separate web page. And in terms of web page, you have a page model, which represented by HTML, basically structure of your page. Then you have CSS, which represents all things on page. And you have JavaScript for connecting things together and like orchestrating behavior on this page. And in the end, you can look at it as a canonical case of MPC, right? That's what basically makes it so strong and sustainable technology. That's what makes the whole web export and we have all variety of things going on. And the great thing about web is all the MPC is that actually every part of it is basically a different language, right? Different tools. And it creates this strong separation between concerns and a developer pretty much can write one table software from the very beginning. On the other hand, we have this typical desktop requirement which was coming from like things like Java, Swing, GTK, QT, where we do everything with pretty much like programming language, right? So whenever you need to maintain a structure, style sheets, can you hear me guys? I don't have any feedback from you. Oh, great. So in this desktop environment, we kind of have things in different way. And because I spent so much time on developing web, developing desktop style always felt like a bit of a drag because the cost structure itself always dance. You always need to take care of all the dependencies and orchestration you do pretty much on your own, which is great for some cases, for someone. But when you switch between web and desktop, it's always like extra load. You need to kind of be in two different mindsets. So whenever we develop anything for web now, clients want things on mobile as well, right? Because mobile traffic grows, you need to be present in there. And every time you're working on your project, it's basically the same question like whether you're web or native. And despite all the merits of both sites, you kind of end up with hybrid applications, right? Which is like huge compromise and not really works all the time. Like it's a case solution when you just need to present a bunch of buttons and images and show some content. It works all right. But whenever you need to do actual integration with the operational system, like access resources, like simplest things, if you ever developed with say Cordova, simplest things like in application payment is always huge pain in the neck because you need to create all this mapping between native operations system and web views. It goes ugly really quickly. So then early motion appeared, right? And I got really excited about it because it's like 100% Ruby. And I'm a Ruby Dev. I do Ruby like every day, 10 hours a day. And I thought, yeah, it's going to be great. And it's compiles everything to native code, which is amazing. Like the thing I actually runs Ruby application is transforms all your code in actual byte code of application. Mind boggling. I had high hopes for it. I still... But in terms of like actual development process, it is still pretty much desktop oriented, which is again fine completely, in many cases, and like challenge. I can hear you. I actually see. Second. It actually did. Are we back? Keep going. Yeah, it is pretty much like classical case of iOS development with early motion. You develop everything in desktop style development and you can Google any answer, right? But unfortunately, if you are facing challenge of building native application as a web developer, the learning curve can be pretty mad, right? It might take you like a few months before you can actually work towards the distance and make the minimal things good. Which made me thinking like in both native and web development, we're basically dealing with the same exact issues. We're dealing with basically presenting content, handling user input, like click stops, everything. Everything is exactly the same. The difference is how we approach. The difference is actually on the cultural level. Because in the web, we got used to certain ways of dealing with things with CSS and HTML and JavaScript. We intuitively know where everything goes. So when we get thrown to desktop development environment, we often get overwhelmed and lost. The learning process is not always worth it because you're learning to do the same thing in a different way. Which made me thinking like now with RubyMation, we have Ruby. And as Ruby developers, we're pretty much abstraction happy, right? So I thought we can build something around it, right? Consider this. What if we think of tapping on an application on your application dashboard as entering a URL in a browser, right? And then multiple screens inside of your applications, we can look at them as kind of like multiple web pages on the same website, right? So what if we treat a native application as a web application? They deal with exactly the same thing. And we can pretty much map all concepts from native development to web and present and create this abstract environment which will let you develop native applications with your basically web developer toolkit. So as a web developer, we can just jump in and immediately understand what goes where. And the environment will be kind of like a web browser and a website compiled into unlinked file. Only there is no web browser, right? It's just abstract environment for you. This abstract environment lives in parallel with the actual operational system. It's just a thin wrapper around it. So whenever you feel like it, you can always call the system level. You can access file system. You can access network, whatever thing separation system provides you with. Like, I don't know, access to contacts, payments. This guy is the limit. So that might let me to build this project called under us or shortly UOS. The best way to explain it and show it is probably just to show how it works. So I'll just build a small application with under us. It's available as a Ruby gem. You just install gem install under us and it provides you with a template for RubyMotion. So you can just go in and create a motion project. Yep, totally. Is that good enough? Awesome. Just specify the template and it will generate you the application. Let's make it a bit larger here as well. So it is a kind of normal RubyMotion application. You have write file and in gem file it just includes under us. But inside the application we have extra things. We have a thing called layouts, which allows you to specify like every screen as a HTML page pretty much and with normal HTML tags. And then you have styles with CSS and pages which basically provide you with execution context for every screen. If you want, it's a pretty much UI controller, UIU controller in iOS. One-to-one mapping, but we treat it as a web page. So you can just write it and it will build everything for you like all dependencies and stuff. Under us itself is kind of modular. It builds things on top of RubyJumps. So at the moment there are a few of them already. There is core which Bootslot thinks. There is a UI which handles all this magic with CSS HTML. There is Ruby like wrapper for HTTP which supports sessions. You can do all interactions with network kind of like Ruby style. In the end it compiles it and copies stuff over and should launch any second now. Here we go. So it's just one button, right? And you can tap it and it shows you alert. And as you see, this thing is already mapped to native alert screens. So we're going to build a calculator application. So we're going to need a bunch of buttons. Most of HTML tags are already mapped. So we have buttons, input fields, labels, numbers. Now we need operations. Last minus slash multiply. And we also need the upper row like clear. Last minus and percent. We will have a label to show the result of our calculations on top of it. Specified default value. Here we will need to show some rows and numbers. Let me quickly fill them in. So that's the first row, the second five. And columns, this one, two, three, this one, four. Let's run it. So all these buttons, they are just on top of each other because we have one shared CSS over here. I've got one prepared, so I'm not going to bore you to this with writing CSS. So a bunch of, basically, how about now? Okay, so I just copy pasted a bunch of CSS, which I wrote before. So we can rerun it now. Broke something probably in here. Row one. Give me a second to figure it quickly. Obviously, the column run. That's the third column. One, two, three. One, two, three. One, two, three. There's all fours. Specified run column. The zero button will have a double size. We also need to... I also have a bunch of extra classes for operation buttons and some classes for upper row. Right? That should fix all our problems. Did it come back? So it fixes all the buttons, but we don't see the labels. And here I want to show you a quick trick. Because it's all HTML and CSS, like virtual. I have a little helper called u. It's kind of like $ in jQuery. You can just go in the console and type it. How about that? So I have a global function called u. It's kind of like a $ sign in jQuery. You can just traverse your page structure with it. Say, find result label. And it will have things like text, properties, style. And you can assign things like get parameters or set them, like, I don't know, 80. If you can see, it moved. You can just specify, like, a hashing here. Like, white, 300 pixels, 8, 80. Position, top, 80. Phone size, say, 80. Color, white. Text, align. Right? And that will magically apply. We support most of the CSS properties. Right? It's still, like, working in progress, but most of the essential things like geometry fonts, some shadows, already borders supported. So you can manage pretty much things with CSS. I have it right here already. I'll just uncomment it and it will look kind of right. Let's make sure that I didn't break anything. So now let's just connect buttons to things. And that's normally done in the pages. In the pages, you can, again, traverse again around your structure of your page. Say, you can find label, result. Right? First, result, come on. And then we can find all buttons. Get each button and assign the top event listener to the every button. And it's done the same exact way we do it in JavaScript and front-end. You just specify on top and give it a callback. And instead of callback, we use blocks in Ruby. And there will be an event and then we can handle it. Just give it event, target, text. Target will point to the button which triggers the event and text is basically text of the button, the property of it. So here I'm just printing the whichever button was typed just to see that it all works. Now we can add some logic around it and make things actually work. And we will use some merits of Ruby because Ruby is awesome. So when it's a number or say a dot, we just get our result text appended with the pressed button. We probably also need to reset the text to empty string if it's current one is zero. So it will have a normal calculator. We can type things in. When it's operation like plus, minus, multiply or divide, we firstly store the operation itself and then we store the first number. We also need to make sure that if it's a first number, then we need to, after operation was pressed, we will need to reset the label and let the next number to be typed in. No, it's, you're right. Thank you. So we're storing the first number, making sure that it gets erased for the next one and then we handle things like equal, which will do calculations and probably clear button which will reset stuff. Let's write those two functions in here. Reset is simple. First number, meal, result, text, empty. Calculate is basically like there are many ways to do that, but I do the simple thing. Values get the first number and current text and then just kind of wrote everything to floats and integers. Stupid is where I know. Number then value to f, else value to ei. So we have two numbers and then just get a result here. That will basically create the result of calculations which I can again feed back into the result text. We need to convert it to strings because text eats strings. That's pretty much it. Shoulder work, fingers crossed, success. That was back to the presentation. So why under us mothers? Why do I do this? Firstly, it is web depth friendly. It transforms all the concepts from native development to web development. So any web dev can jump in and start making things quickly. It doesn't mean that he doesn't have to learn any native application. It just will keep going quickly. I keep write application with tool set here already familiar with. It's also Ruby friendly. As you noticed in my little exercise, we haven't attached the iOS API at all. Like there is zero. We didn't do our logs. We didn't call any. We start from iOS. Ruby, all nice initializers. So you can pretty much abstract everything from actual operational system. It is independent. Unlike, say, a browser and web development where we have all this huge heritage of web browsers with doms and different ways of dealing things. We don't have it. We're in control of this API. You can make this web-ish abstraction to behave sanely. Like say it was a browser with jQuery built-in. All same things are in there and available. And it's totally hackable. It's really, right? So whenever you feel like you need to change things, you don't need to kind of bang your head against the wall and blame it for doing weird things. You in control, you can always change things in there. Monkey patch or make a gem. It's completely extendable. iOS supports easy extensions through RubyGems. That's kind of like one of the goals of the project is to make it easy, extendable through RubyGems. I already have a few gems in there in my projects like, I don't know, five, six gems and it's easy to make ones. And the big what if, you all aware for yesterday news that RubyMotion will support Android. My original goal was to make under our support both iOS and Android in the background and I was going to do Android with a Rabuto project. If you know there was a project called Rabuto which allowed you to run Ruby on Android. But with this great news from HeBite and the announcement that RubyMotion will support Android, it's now a clear path there. So we can create all this abstraction which can basically make you create a native application with the same exact code just in the background with switch engine depending on the build. That's now pretty much a reality we can get there. And that's my whole talk. The Android Rust project is on the web, it's on GitHub, it's fully opened, available for MIT license. That's my Twitter handle, shoot me a message. Let me know.