Motion in the Middle: RubyMotion as a Gateway to Mobile Development

Editor's Notes

• #2: Hey everyone, I want to quickly thank the organizers for having me and all the other great presenters today. Really quick, a few details about me…
• #3: . I’m a developer at Cyrus, a software shop in Soho, we do mobile and web apps for startups and enterprise. I am a proud graduate of the Flatiron School right here in NYC, a program that’s changing lives (like mine) and the NYC tech scene, check ‘em out. I’m also the organizer of RubyBlind, a meetup where we host talks on Ruby and other programming languages and tools, as well as a co-organizer of the nycrubmotionmeetup – both of those are on meetup.com so check us out .And in case your interested in reaching out, there’s my twitter handle, github username and blog for you guys.
• #4: . I’m a developer at Cyrus, a software shop in Soho, we do mobile and web apps for startups and enterprise. I am a proud graduate of the Flatiron School right here in NYC, a program that’s changing lives (like mine) and the NYC tech scene, check ‘em out. I’m also the organizer of RubyBlind, a meetup where we host talks on Ruby and other programming languages and tools, as well as a co-organizer of the nycrubmotionmeetup – both of those are on meetup.com so check us out .And in case your interested in reaching out, there’s my twitter handle, github username and blog for you guys.
• #5: I’m here to talk to you about RubyMotion, a toolchain that allows you to build native iOS (and, as of about a month ago, OSX) apps with Ruby! Some of you may have read about RubyMotion before, maybe even tried it, and you may be a bit skeptical about sinking time and energy into this new toolchain, as opposed to learning native development. I used to be the same way.SOME OF YOU MAY HAVE USED BEFORE,MAY BE SKEPTICAL,LEARNING A NEW TOOL INSTEAD OF NATIVE DEVELOPMENT
• #6: Four months ago, found out I was going to be on the mobile team at Cyrus building apps with RubyMotion. I was excited, but also a little wary. I’d heard from my iOS developer friends about BACK TO JANUARY OF THIS YEAR, FOUND OUT ON MOBILE TEAMEXCITED, BUT WARY
• #7: Xcode,
• #8: Interface builder
• #9: and Objective C! There didn’t seem to be any of that in RubyMotion – what was I sacrificing by not learning these tools? Didn’t help matters when an older co-worker of mine saidDIDN”T SEEM TO BE ANY OF THAT IN RUBYMOTION – (THIS IS SORT OF A SELLING POINT) – BUT STILL, I THOUGHT MAYBE I”D BE MISSING SOMETHING,ONE OF MY PROGRAMMER BUDDIES SAID…
• #10: “I don’t know about this RubyMotion stuff”, he said. “You have to learn the Cocoa APIs anyway, so I don’t see an advantage in adding another layer of abstraction.” Was I wasting my time?
• #11: I forged ahead with RubyMotion, and less than four months later, my team at Cyrus and I have built and pushed Flavorpill’s new iOS app to the app store,
• #12: and are working with a company in the UK to have another app for driving instructors in the app store shortly. What happened? How did I go from not having done any iOS development and being a serious skeptic to standing here in front of all of you singing RubyMotion’s praises?
• #13: The central feature of RubyMotion is that it has staked a claim directly in the middle of the Ruby and Cocoa worlds (Cocoa are the Apple APIs). On the one side, you’re writing expressive, flexible Ruby code,, on the other side, that code is getting compiled as native code, making direct calls to all of the underlying APIs. By blending the two worlds, RubyMotion can act as a bridge from web to mobile development for Rubyists. STAKE A CLAIM RIGHT IN THE MIDDLE OF THE RUBY AND COCOA WORLDS. WRITE THE KIND OF CODE RUBYISTS LOVE TO WRITE – EXPRESSIVE FLEXIBLE – NOT SACRIFICING ANY OF THE FUNCTIONALITY OF THE IOS FRAMEWORKS.BLENDING, RUBYMOTION IS A BRIDGE
• #14: Not one like this, pretty risky and intimidating
• #15: but one like this, a solid path to your destination, in our case the excitingworld of mobile development. Now this is important, because if you’re telling your grandma or your mom about my talk later and you can’t think of the main points, just remember a bridge forms an arc. SAFE PASSAGE TO SUPERCOOL WORLD OF MOBILE DEVELOPMENT – THREE MAIN FEATURES THAT CONTRIBUTE TO THIS
• #17: And in that arc are three reasons RubyMotion is a gateway to mobile development.Abstraction in the Right Places - Mixing the speed of Ruby with the power of the native frameworksReading/Translating – by which the RubyMotion developer unwittingly learns Objective C Community - the RubyMotion community is vibrant, growing, and mirroring it’s big brother the Ruby/Rails communityLet’s dig into these a little deeper…
• #18: I know I mentioned this in the intro, but I just want to re-state it: When you build a RubyMotion app, you’re building NATIVE apps, just using Ruby instead of Objective-C.
• #19: Part of the RubyMotion is a Ruby implementation that sits ON TOP of the Objective C runtime, the same runtime that native apps sit on top of (slide). The object model is implemented using this runtime, so all of your classes, methods, data structures, while they look like Ruby, are actually subclasses of their Objective C counterparts.
• #21: For example, a string in RubyMotion, is actually a subclass of the Objective C NSMutableString class. What this means is that we can write the idiomatic, expressive Ruby that we all know and love, but our code is being compiled as native code, without any interpretation, conversion, or sacrifice in performance. AWESOME. On the flip side of this nice little abstraction, the cocoa APIs, the frameworks that we use in build all of the great functionality and interfaces of iOS apps, are completely exposed in RubyMotion. So the RM developer learns the same naked API calls as a native developer.
• #22: Something like launching the app and instantiating your top level screen, which looks like this in native codelooks like this in RubyMotion – really similar, with only some slightly different syntax. I spoke to Laurent, the creator of RubyMotion, about this and he said
• #24: “…by design, we expose the entire sameAPI as the one you would get in Obj-C. The iOS SDK is mature andwell documented…It would have been a bad idea to restrict what you could do with RubyMotion.” You heard it from Laurent, no restrictions or sacrifice in Cocoa functionality in RM….
• #25: This mix of the speed of Ruby and the power of the Cocoa frameworks is a potent combination, one that lets us build highly functioning apps quickly and creatively. Now, that’s little bit about how RubyMotion’s benefits the app, but it also benefits the appdeveloper.
• #26: …and that’s through learning some Objective C. Now, ALL of the documentation, save for the lovingly translated RubyMotiondocset, is in Objective C, so the RubyMotion developer looking for help is quickly going to see some code like this, or like this, and it’s going to make you do this.
• #27: , or this…
• #28: And, it’s going to make you do this
• #29: Natural reaction for a Rubyist looking at some seriously verbose code. But by translating unfamiliar Objective C into our domain, Ruby, you slowly, somewhat unwittingly, learn some Objective C, which is beneficial for two reasons: The first is practical….
• #30: Since it sits on top of the native runtime, RubyMotion apps are fully compatible with pure Objective C libraries. There are a lot of them out there, and you’re quickly going to run into a situation where you want to use one, say for image caching or persistence. When that happens, knowing some Objective C is going to be crucial to figuring out how to use these libraries, and ultimately allows you to use the widest set of tools available.
• #31: The second reason, is that learning Objective C can expose the Rubyist to a number of CS concepts that are going on under the hood in Ruby. Things like Pointers, Typing, Memory Mgmt and Garbage collection are largely abstracted away in Ruby. As Rubyists, we consider this a good thing, and it sometimes is, but when you’re building an iOS app and you get your first weak reference error, knowing a little bit about reference counting and garbage collection is going to go a long way in helping you debug. Learning Objective C through translating from native to Ruby code gives the Rubyist, especially a beginner like me, a vehicle through which to learn these concepts and use them to build well designed, performant apps.
• #32: So where does this leave us so far? We’ve got a solid understanding of the APIs, we’re implementing our ideas quicky using Ruby, we’ve got access to all the native libraries so the sky’s the limit as far as functionality, and we’ve learned some Objective C for troubleshooting under the hood. We’re now building apps with RubyMotion, and the first thing a Rubyist is going to do when you’re in the mud, building stuff? Try to make it better, and that brings me to one of the most exciting aspects of RubyMotion, the community.
• #33: The RubyMotion community right now ismirroring all of the enthusiasm and collaborative spirit of it’s older brother the Ruby/Rails community. Now, we talked earlier about the very thin layer of abstraction over the native APIs in RubyMotion, which is a great thing. The flipside of that, however, is that there’s a ridiculous amount of room to inject DSL’s and Wrappers that make the those API calls more ‘Rubyish’.
• #34: “I decided not to ship rubymotion with a wrapper/DSL mainly for two reasons… first, it is a very hard task, designing a good API takes time and energy,and there is a lot to cover … second, rubyists love to write DSLs (since Ruby is good at it), and i didn't want to steal the happiness” I love that quote because it really does touch on what makes Rubyists happy – contributing, and continually making things easier, more expressive, and better for developers. There are a bunch of gems that have sprung up to do just that –
• #35: BubblewrapTeacupSugarcube/SweetTeaMotion-ModelPromotionIf you like, check these and a bunch of other great gems out on rubymotion-wrappers.com.
• #37: There’s also, in an example of Rubyist bringing their good manners and hygiene to the mobile world, I strong testing culture emerging in the RubyMotion community. Some of the frameworks being used are: list testing frameworks.  MacBacon – ships with RM, a small rspec port for iOS, great for functional and unit testingMotion-Frank – cucumber acceptance testing, using the Shelley framework to give you all kinds of touch/scroll/pinch/tap user flowsMotion-Facon – mocking and stubbingWith the strong tradition of TDD in the Ruby/Rails world, it’s great to see this spilling over into RubyMotion, because well tested apps result in better applications, more modular design, and fearless refactoring, all of which result in freedom of creativity.
• #39: Contributing frameworks and libraries, it’s what we do . This is where Rubyists really shine, and as Laurent pointed out, it’s what makes us happy. There are endless opportunities for contribution’s to the RubyMotion ecosystem, and the community really something special to be a part of, and one of my favorite things about being a RubyMotion developer. 
• #40: So, what do do now? Get started – there are a bunch of great tutorials on line, there’s an excellent RubyMotion pragmatic programmers book, Laurent and the HipByte team are even offering their own training course, and the RM google group is outstanding as far as questions and troubleshooting. If you’re still skeptical about RubyMotion vs. native development, you’re certainly entitled to that and there are some great things about Objective C and native development, but I’ll just say this –four months ago, I had never done any mobile development, RM or otherwise – now, I’ve got an app in the app store and another on the way,and I’m fully immersed in a toolchain that’s making mobile development fun, envigorating, and creative. I owe that to RubyMotion, so I encourage all the Rubyists here to check it out and make your mark on the mobile world. Thanks!