RubyMotion: Earl Gray with Sugar

An Earl of the RubyMotion Community explains Sugarcube

Ruby lends itself well to the creation of Domain Specific Languages (DSL).

If you are approaching iOS development for the first time, you will likely have one of these consistent reactions based on your background

• Heavy C/C++ : This Objective-C should not even have “C” in its name!
• SmallTalk or NeXT : I am home again
• Ruby: WTF?

As was described in a previous article, RubyMotion carried an implied promise of “Ruby to replace Objective-C”. That was really not quite the truth. Even though RubyMotion is a toolchain that compiles Ruby (or Ruby-like) code into an iOS executable, there is no shortcut to understanding the structure and architecture of iOS and Objective-C.

In the RubyMotion community there have been many efforts to “soften the blow” incurred when a hard-core Rubyist encounters the Objective-C Behemoth.
Bubble-Wrap (so aptly named) was the first and remained the most popular for quite some time. It helps to ‘wrap’ the obscure and confounding syntax required by iOS in a more Ruby-esque style.

The ultimate in Syntactic Sugar came along with SugarCube. SugarCube is almost an entirely new language, written as a DSL, for RubyMotion.

The “Man behind the Curtain” for SugarCube is Colin Thomas Arnold Gray.

Colin’s efforts in the RubyMotion community, particularly with his DSL named SugarCube, has earned him an official position as Community Manager within the RubyMotion Community.

I spoke with Colin about his background, his introduction to RubyMotion, the history and evolution of SugarCube and his new position in the RubyMotion Community.

The Interview

Thom: Tell us about your background and your introduction to Ruby (and RubyMotion).

Colin: Yeah, I learned early on that I like to build tools, things that other people use. I also like to build products, but I like to build tools more. I like to be writing reusable code. So even if it’s just for me down the road, I enjoy that aspect of it a lot.
It is Fun to tinker. Of course, coding is such an fortunate profession because it’s a tinkering job and we love it and we get paid to just tinker all day.

Thom: You said you were working, in Denver, in PHP – helping to build a Framework – about the time the first PickAxe book was published. So Ruby had interested you, but it was not a primary language for you at that time?

Colin: So I got interested in Ruby, and like I said, I was writing our own framework. So I based a lot of it on ideas from Rails; the ORM was very different, it had more access to raw SQL.

So Ruby was kind of ‘over there’, it was something I wanted to use, I would read it, and try and learn more about it, but I wasn’t using it every day, and wasn’t making anything with Rails.
But at that time, it was really hard to configure a server to use Rails, so PHP was just the fallback. Every server supported it.

Then it got set aside for a while because we switched to Django and Python, and then I was doing Python most days, and so Ruby got set aside. This whole time, the iPhone was out, and I wanted to be doing apps for it. I kept picking up Objective-C and iOS books. I already knew Objective-C, so I was thought, “I should be able to do this.” But I couldn’t quite sink my teeth into it. I think one issue was time. I wasn’t doing it professionally, so I didn’t have all day to play with it. The other was the work flow, and the things that I think a lot of RubyMotion programmers identify immediately is it doesn’t feel natural.

Thom: I think that’s a common thing. With Xcode, it’s a nice IDE, I guess from Apple’s perspective, but there’s something about it that just feels so clumsy.

Colin: Yeah, and it hides so much, you really don’t have a feel for what happens when you create a navigation controller. Where do you add the view again? Does it have to be the root view controller? Can it be a sub-something of something else and what are those things?

Thom: Yes, you are right, it kind of GUI-fies it too much.

Colin: Yeah, It’s silly because once you do figure it out you realize, there’s no magic to a UINavigationController. It is just a dumb container. You could write your own nav bar in an afternoon, it wouldn’t be as full-featured and it wouldn’t integrate as well, of course, but you could just write one. It’s not magic.
But Xcode makes the magic because you don’t see what is actually happening.

Thom: I think Xcode was trying to be what Visual Basic had become. You know, Visual Basic made it so easy for just about anybody to write bad software.

Colin: That’s right. I wrote my share of it.

I decided to learn Objective-C when I was a student, in Japan. So then I wanted to follow up on it. I had a lot of time and a lot of drive to get really good at it.

So I thought, “Okay, I’ll make an app, an application for Mac OS X, and let’s see, what app could I make? I’ll make a spreadsheet.” That was my ‘genius’ idea.

I thought, “I’ll have a spreadsheet and it will have a whole language in it, not a spreadsheet language, but a whole entire thing.”
And I wrote the language, I called it LX, which stood for “Like Excel,” but backwards. So XL backwards.

Thom: That’s clever.

Colin: I actually started the spreadsheet program and got very far along and it was actually very similar to Numbers in that it didn’t have the spreadsheet as the root object, it had a document, and you would drag tables onto it, and you could drag charts onto it. The tables did tabulate data and you could put formulas in them and the formulas could be a mini program. So it was pretty cool.

Thom: So how and when did you discover RubyMotion? You’ve been involved in it from very early.

Colin: I had totally by chance stumbled on MacRuby. I think maybe I Googled, “writing Mac OS programs in another language,” because I knew, you used to be able to use Java and you used to be able to do it in this and that, and I had heard of PyObjective-C or something. In that search MacRuby was number one. You could write and it runs natively! Well, that’s, wow! This is really cool!

I became really excited about it. I’ve been doing web work for so long and doing that really well. I wanted to get into some desktop programming, that would be neat.

So I hooked up with that crowd. I remember Joshua Ballanco. Laurent wasn’t around. I’d read his name, he was the creator, but he was conspicuously absent. But there were a few other people, I can’t remember his real name, but Ferris26, and Joshua Ballanco, they were the main two that were hanging out, especially Joshua, he is just so forthcoming with help and information.

“I am going to totally jump into this”, I thought. I read Matt Aimonetti’s book on it and then was talking to Josh about, “What could I do? What could I write for this community? What’s useful?”” And of course, the answer was DOCUMENTATION.

Thom: Yes!

Colin: Always documentation. I was thinking of doing a CoreData tool, something to make CoreData easier. And it was right at that time, right as I was just itching to sink my teeth into a bigger project, that RubyMotion was announced, and it was just, the clouds parted and light—

Thom: Serendipity.

Colin: It was even better than finding out about MacRuby. I wanted to be doing iOS development, I wanted to be part of this Mac Ruby world, and there it was, all together, all at once. So I jumped in, I pulled up the RubyMotion room on IRC. There were already a few people there, maybe ten or so. Everyone was excited, just, “It’s so cool!” It compiled, it actually compiled, that was just crazy.

I think Matt Aimonetti had already released BubbleWrap and then in that chat room, we talked about the idea of this view DSL and we all agreed, let’s have it be a community project. So of course we had to figure out the name. We played around with different names, and let’s see, someone said – I think it was Chris Clark – “Like what if we had tea instead of cocoa.”

Colin: So we started Teacup and it started off as only Wiki pages. You could submit a proposal for a syntax, and we would all debate it, some better than others, and we ended up with – it was Conrad Irwin’s suggestion – based on these other ones.

I started working on SugarCube as an assist to Teacup. I was looking at Teacup and thought, “Well, that’s pretty low level, as it should be, but I don’t want to write all this stuff out, I want to be able to just say ‘white,’ as SugarCube does.”

I eventually took the teacup project over. I think the first thing I added was handlers. They are used to translate value in the stylesheet and assigning it to whatever method or property. There’s this opportunity to say, “Well, hold on, what do you want to do with this value?” So that’s where you can turn a color symbol name into a color object. That goes through a handler.

Thom: So your introduction, or rather the thing that seduced you into RubyMotion was this opportunity to be involved in a community project.

Colin: Right.

Thom: And also realize your initial goal of writing some sort of a DSL around the Ruby language. Did I characterize that correctly?

Colin: I think so, yeah. Okay. So my favorite, the part of SugarCube that I ended up being most pleased with is by far the REPL tools.

Thom: Yes.

Colin: Every time I jump into a new project it’s just the very first step.

Thom: Suppose you were in an elevator and had 15 seconds to convince somebody who’s never heard of it, why they should look at RubyMotion. What are the things about it that come to your mind, that are so exciting?

Colin: When you work with RubyMotion and you’re in an iOS world, RubyMotion puts you right at the heart of it, all the tools; like working with the REPL and writing out your code. You start in the AppDelegate, you create your window, you set everything up, you’re working very close to the metal. So there is maybe a higher learning curve, though also you learn it pretty quickly, a lot of it you can just copy and paste the same Application Delegate code in every time. As you proceed, you’re always going to be getting it, it’s going to force you to learn things thoroughly. That’s one reason.

It’s tricky, because there’s pluses and minuses. And one thing I’ll preface with or mention is, I don’t try very hard to convince people to use it, because it’s such an odd decision.

Thom: I agree with that.

Colin: It has to feel right and when it does feel right, you’ll know it. It’ll feel intuitive, it’ll feel like the right tool for the job and Xcode will not, Instruments will not, you won’t want to use those.

So one great reason to use it is because it’s an alternative and because it’s there and because it might feel like the best tool for the job. If it doesn’t, don’t use it. But I’m not trying to win any battles.

SugarCube

Thom: Tell me a litle more about Sugarcube. What was the inspiration for that?

Colin: You’ve got the REPL there and you could click on views but you can’t click on all of them. There’s a lot that won’t register and, of course, if you’re in Retina, won’t register any of them, for whatever reason. The command click trick doesn’t work.

So I went, “Okay, this is silly. What I should be able to do is just look at hierarchy, that’s what I’m doing, I’m just traversing the hierarchy, I want something to do it for me.”

So I wrote the Tree command. The output starts at app window, and you can go on down. Then immediately followed up with the adjust command. So that came about and it’s just huge. It’s so helpful to see what is going on. And so now that actually kind of leads my programming a certain way because I always make sure that when my views are output that all the important information is in that Tree View.

Then the other thing that the Tree View can do is output any Tree-like structure, mainly layers, so you can do your layer, your core animation layer hierarchy and view controllers. And you can say “tree root,” and that will give you all your view controllers. And between those things, you’ve got most of what you’re working with every day and they’re just very easy to get to.

Thom: SugarCube is an amazing DSL that helps simplify the transition [from Ruby] to iOS.

A RubyMotion Ambassador

So tell me about this thing with HipByte, because that was very exciting.

Colin: Yeah, so having written SugarCube and Teacup, that put me in a spot for Laurent to ask me, back in November, he told me about the conference — it didn’t have a name back then — and back then it was going to be in early February, and would I come and talk? I was just blown away. A conference had never asked me to talk, it was absurd. So that was pretty cool.

Well, that introduced us to each other more than support tickets and a here and there and IRC’ing, so then we were kind of chatting more often about the conference and who’s going to talk and what’s going on in the community. It was very apparent that he wants to work on RubyMotion, he’s a programmer, he’s not a manager, he wants to work on his product and he only has so much time to take part in the community. That’s a big bummer because he wants to know what’s going on, but what can you do? So I would kind of feed him information. Here’s a Google group chat, you should look at this, you should chime in here, this is important. Someone’s trying to, recently someone was having trouble with Cocos2D, and I sent that to him and said, “I know that Cocos2D integration is important, so what do you think about this?” And he and Watson kind of chimed back in on that.

Then at one point he asked if I would be interested in an actual position as this community liason person for HipByte. So what that would entail would be writing blogs and writing tutorials, interviewing people who write gems and just kind of keeping the finger on the pulse, making sure that the best product, the best projects and gems keep getting managed.

So like the story of BubbleWrap, where Matt Aimonetti decided, “I don’t want to maintain this anymore, I don’t have the time.” So getting that transitioned to the other BubbleWrap programmers. Now, they of course, handled that themselves, but making sure that that thing happens.

Thom: So do you have some sort of official title?

Colin: Yeah, the working title and I don’t know if it’s “the” official title, but Community Manager is the position.

Thom: Okay.

Colin: And right now it’s a very limited role. I’ve got a HipByte email address and I’m kind of inside the building.

Thom: But you’re really more a member of the community, representing HipByte?

Colin: Yeah. The best part, actually, of that role is that it does entail maintaining the projects, the open source projects.

Thom: That’s wonderful. And I think I saw one tweet about your battery dying, I think that’s when you guys were having the discussion.

Colin: Yeah. And that was something I meant to mention earlier, that that was another thing I wanted to do, and that got transferred from Mac Ruby to RubyMotion, was the really being an active member of a programming community. So I had watched Django more from a distance, and that was the first big software project that I was using that I could maybe chime in on, but that’s an old boys club already. It’s been around for a long time and they have their members who chime in and who answer, so I just kind of sat on the sidelines.

With RubyMotion, there it was, I could just jump right in. I decided to answer as many questions as I could, even if it’s going to be a little annoying. Even if I don’t know completely, if I just have an opinion, I’m going to be active, that’s just what I’m going to do. It was really great to see that play out.

Thom: I think it has served you well.

Colin: It has.

Thom: As I said, you’re kind of a celebrity and your moniker is recognized in the Google group.

Colin: Yeah, it took a lot of work. On the one hand, it could be anybody, you know, because there is that whole group of active members, especially on the Google group, I think, you just, they pop in and you just see them, you know?

Thom: Yes.

Colin: And it’s such a great community, too, it’s been such a pleasure to see the emails and watch it grow bit by bit and everyone is so happy to be there, and I really do think of it as like watching the Rails community, if you had gotten in early and were watching it grow and just kind of like, “Oh, my goodness!” That’s been my experience of it.

Thom: Finally, I just wanted to get kind of your perspective. Is there anything that you see outstanding as being something that’s missing that you would like to see in RubyMotion at the moment?

{ At the time of this interview, Colin mentioned a “secret project”. That was unveiled at the first RubyMotion Conference, #inspect }

XRay – Expose your RubyMotion Application

Thom: Tell me about your newest project: Xray.

Colin: The idea for Xray came when I was showing off a new app feature, and was asked for some simple changes:

• swap the locations of a couple views
• change a font
• change some colors

Those kinds of things. If I was on a browser, I would be able to pull up firebug/web inspector and bam do it right there. Or, if I was on a terminal, I would be able to use RubyMotion‘s terrific REPL to move things around. But, sigh, it’s on-the-device. So back to the computer for code/compile/view/upload/repeat cycle.

The idea struck me that if I could just edit these things in place, I could show those changes in minutes, right there… better yet, I could hand the phone to them and say “go crazy”, and THEY could make any changes they wanted. Of course that would require some logging mechanism, but that’s reasonable… And that was the start of Xray. Very early in development I realized that while UI editing was “neat”, there was more here that could be done. A console log would be easy to implement, and very handy! So that got tossed in. Austin Seraphin was going to give a talk about accessibility at #inspect, and an idea occurred to me that I could show a visualization of the accessible views, so the “accessibility” plugin was created.

When possible I like to aim for extensible systems – they make code cleaner because they force a separation of concerns. So that was an easy win. Now of course the ideas for more plugins keeps growing: memory usage graph, cocos2d framerate/number of textures, autolayout constraints visualization (VERY hard!), scanner for bluetooth devices, network usage logging – and ideas that never would have occurred to me have been popping up! One that comes to mind: Joffrey Jaffeux is building a plugin that displays environment variables, and you can edit them. So you could switch from your “development” server to your “production” server, for instance, or edit some credentials in order to mimic a user who is having trouble! So not just a development environment, you can use Xray as a “superuser” tool as well! How handy would it be to have a “login as user X” feature on JUST your app!?

The feedback from the community has been great – I think people understand the value of having these things on the device, so you can actually do some debugging and introspection from, say, the subway, where network connectivity is spotty.
There are a few things that are particularly difficult to test on iOS – whether you’re using RubyMotion or XCode.

Thom: Thank you very much, Colin. I hope you continue to innovate on behalf of the RubyMotion community.

Colin Thomas Arnold Gray is extremely active in the Google Groups. He can be found at www.colinta.com, Colinta in Github and @colinta on Twitter.