00:00:15.920
Alright, what's up guys? I just want to quickly thank the organizers and the other presenters. They're a great bunch of people, and this is an awesome conference, so thanks a lot. A couple of things about me: I'm a developer at Cyrus Innovation, a software consultancy in Soho. We focus on web and mobile apps, particularly with RubyMotion. I'm also a proud graduate of the Flatiron School, which is right there and a sponsor of this event. They are an amazing organization, turning people into programmers and changing many lives.
00:00:26.070
Additionally, I'm the organizer of Ruby Bloke, where we hold monthly meetups focused on Ruby and other programming languages. I'm also a co-organizer of the NYC RubyMotion meetup. If you want to check us out, we are available on Meetup.com. If anyone wants to reach out to me personally, feel free to connect with me on Twitter, my blog, or GitHub. I'll be around the rest of the day, so definitely reach out.
00:01:11.850
Now, let's talk about RubyMotion, which is an awesome tool that lets you build iOS and, as of about a month ago, OSX apps with Ruby. Many of you have probably heard of RubyMotion. Some of you may have even tried it and might be a little skeptical about investing time and energy into learning this relatively new toolchain instead of going the native route. I was the same way about four months ago when I found out I was going to be on a mobile team at Cyrus, building apps with RubyMotion. I was super excited and stoked but also a little wary.
00:01:31.409
I had heard about things like Xcode, Interface Builder, and even the dreaded Objective-C, and there didn't seem to be any of that in RubyMotion. However, I came to find that this was actually a selling point of the tool. At the time, though, I was concerned about what I might be sacrificing by not learning these things. It didn't help when an older developer friend told me that it didn't make sense to use RubyMotion since I would need to learn the Cocoa APIs anyway, suggesting I was adding another layer of distraction. So, was I wasting my time? Well, I forged ahead with RubyMotion, and now less than four months later, my team at Cyrus and I have built and pushed Flavor Pills, a new iOS app, to the App Store. It's looking pretty cool. We're also working with a startup in the UK on a fantastic driving instructor's app, which should be in the App Store shortly.
00:02:05.940
So what changed? How did I go from having done no mobile development and being skeptical of this toolchain to standing here singing RubyMotion's praises to all of you? What I found out is that RubyMotion stakes a claim right in the middle of the Ruby and Cocoa world. For those who don't know, on one side, you're writing expressive, beautiful Ruby code. On the other side, that code is compiled to native and makes direct calls to all the underlying Cocoa APIs. By blending the two worlds in this way, RubyMotion acts like a bridge from web development to mobile development for Ruby developers; not a scary, intimidating Indiana Jones bridge, but a solid path to building mobile apps.
00:02:38.099
This is crucial because if you're telling your mom or grandma about my talk later, which I know you will, and you forget my main points, just remember that a bridge forms an arc. In that arc, there are three reasons why RubyMotion is a great way to get into mobile development. The first is abstraction in the right places, mixing the speed of Ruby with the power of the Cocoa frameworks. The second is 'reading and translating,' by which RubyMotion developers unwittingly learn some Objective-C, which is a positive aspect, as we will discover. And third, I’m excited to talk about the RubyMotion community, which is just awesome and mirrors its big brother, the Ruby on Rails community, in many ways. Let's jump in.
00:04:06.060
When you're building RubyMotion apps, you are genuinely building native apps, just using Ruby instead of Objective-C. Part of the tool is a Ruby implementation that sits on top of the Objective-C runtime, the same runtime that native apps use. Your object model is implemented using this runtime, so your classes and data structures look like Ruby, but they're actually subclasses of their Objective-C counterparts. For example, a string in RubyMotion looks just like our familiar Ruby string, but it’s actually a subclass of the Objective-C 'NSMutableString' class.
00:04:31.800
What does this mean? You can write idiomatic, beautiful Ruby code, but under the hood, that code is compiled as native, resulting in no conversion or interpretation—meaning there's no loss of performance, which is fantastic. On the other end of this abstraction lies the Cocoa APIs that we use to build out all the wonderful interfaces and functionality in iOS apps. RubyMotion developers have direct access to these APIs in their entirety; they are completely exposed. You make the same calls to these APIs that a native developer would make.
00:05:00.280
For example, launching your app and instantiating your top-level screen looks quite similar in native code and RubyMotion, with slightly different syntax. I spoke to Laurent, the creator of RubyMotion, about this, and he stated, "By design, we expose the same APIs that you would find in Objective-C. The iOS SDK is mature and well-documented, and it would have been counterproductive to restrict what you could do with RubyMotion." So, according to Laurent, you are not sacrificing any Cocoa functionality when building a RubyMotion app.
00:05:37.560
Mixing the power of Cocoa frameworks with the speed and expressiveness of Ruby creates a potent combination. We can build highly functioning apps with RubyMotion and do so quickly and creatively using our beloved Ruby. This not only benefits the app but also the developer because it encourages learning some Objective-C. As any of you who have tried to build iOS apps know, nearly all the documentation is in Objective-C, save for the lovingly translated RubyMotion docs.
00:06:01.400
When you go looking for help, you are most likely going to see code that appears a bit complex or verbose. This can initially be overwhelming for Ruby developers, but over time, as you start translating from unfamiliar Objective-C into our domain, Ruby, you begin to learn some of the nuances of Objective-C. This is beneficial for several reasons. First, since RubyMotion apps sit on top of the native runtime, they are fully compatible with pure Objective-C libraries. You will likely want to use one for persistence, image caching, or any number of reasons. Therefore, knowing some Objective-C will be crucial in effectively utilizing that library and broadening your available tools.
00:06:39.700
Second, Objective-C introduces several computer science concepts that are largely abstracted away in Ruby. This includes things like pointers, typing, garbage collection, and memory management. While we often view these aspects as unnecessary when working with Ruby, they become crucial when you're building a mobile app. For instance, understanding reference counting and memory management becomes invaluable when you encounter your first memory management error.
00:07:06.820
By learning Objective-C through translating from Ruby, beginner Ruby developers gain a productive introduction to these concepts, allowing them to build better-performing apps. So far, we've established a solid understanding of the Cocoa APIs because they're fully exposed, and we can quickly implement our ideas using Ruby. Moreover, since we can access all Objective-C libraries, the sky's the limit.
00:07:27.700
As RUBIO developers, our instinct is to improve and simplify our processes, which brings me to the RubyMotion community. This community is fantastic. We previously discussed the minimal layer of abstraction above the Cocoa APIs, which is beneficial, but the opposite side is that there's immense potential for us to create domain-specific languages (DSLs) and wrappers that make those direct API calls more Ruby-like.
00:07:57.580
I also asked Laurent about this, and he mentioned that he chose not to ship RubyMotion with a wrapper DSL for two main reasons. First, designing a good API is a challenging task that takes time and energy, and there's much to cover. Second, Ruby developers love writing DSLs because Ruby excels at it, and he wanted us to enjoy that process. His intention was to ensure developers find happiness in creating and contributing, and I think that's wonderful.
00:08:27.000
Let me quickly list some of the gems in RubyMotion currently elevating the developer experience. For example, Bubble Wrap simplifies HTTP requests, Teacup allows you to write CSS-like stylesheets for your UI layouts, which can otherwise become unwieldy with Cocoa frameworks. Then there are Sugar Cube and Sweetie, which provide syntactic sugar on top of libraries, and Motion Model, which is an Active Record port for RubyMotion. Promotions is also receiving attention lately as a cool application framework.
00:09:01.260
This is just a quick overview; you can explore these and others on RubyMotionRobbers.com if you're interested. Notably, there's incredible hygiene and best practices being maintained within the RubyMotion ecosystem, evident in the frameworks and tools being utilized. For example, MacBacon—an RSpec port bundled with RubyMotion—motion Frank, which facilitates Cucumber integration testing for iOS, and Motion Fakin, a mocking and stubbing library I’ve been enjoying extensively. There are plenty of others, so I encourage you to explore them.
00:09:37.760
In summary, this is what we do as developers—we contribute, creating frameworks and libraries that enhance the RubyMotion experience. Since RubyMotion is quite a young community, there’s still plenty of room to make a mark and contribute to its growth. This aspect of the RubyMotion community is one of my favorite things, and I believe it will excite you too.
00:10:00.000
So, where does all this leave us? Well, I’m wrapping up, but I encourage you to delve into RubyMotion. It's an exciting tool, and I'm thrilled you all joined me today. Thank you so much for your attention!
00:10:24.960
Thanks, guys!
