Clay Allsopp

RubyMotion - Year One

2013-05-05T00:00:00-07:00

RubyMotion: Year One

One year ago, this post appeared at the top of Hacker News. It was one of those mysterious moments where the exact thing I was looking for showed up, I kid you not, mere hours after my cranial lightbulb flickered on and illuminated what I wanted: "Ruby for iOS. Bingo."

See, I had been exploring projects like Nu and Wax and even hacking around JavaScriptCore, trying to find a different path of doing iOS development. The whole Xcode/Objective-C workflow is fine and had worked for years, but compared to how we build web apps something just didn't sit right. Not so much a "painful" difference that prevented me from getting stuff done, but more of an "awkward" or "uncomfortable" tension that we all kind of go along with because hey, that's how it's gotta be, right?

I guess I wasn't alone in thinking, "Nope, it doesn't have to be like that." I bought RubyMotion on that release day, and I still get that "new software" smell tingling in my nostrils whenever I remember my first attempts at building something for it:

Having too much fun with @rubymotion tonight instagr.am/p/KRvR3cmx_M/
— Clay Allsopp (@clayallsopp) May 6, 2012

(or yeah, maybe it's just the funky odor of the place I was living back then.)

Anyway, it's now been a year since RubyMotion came to town - what's happened?

I think one good visualization is the commit history for the RubyMotion-Wrappers site, which is a sort of community-curated database of popular RubyMotion projects. I launched it shortly after the release of RubyMotion with 10 initial projects; since then, it's quadrupled in size and continues to have steady growth every week. The community has released libraries for everything from ActiveRecord ports to game engines to rethinking how we structure iOS apps.

According to RubyGems, the most popular RubyMotion projects are SugarCube and BubbleWrap, which have been downloaded more than 50,000 times. That's also a fun metric to use as a proxy for how well HipByte (the company behind RubyMotion) is doing, so I don't think you should worry about them going belly-up any time soon. And if you want to be on the ground-floor of the scene, the Google Group is active with new posts every day.

We're using RubyMotion in production at Propeller, as are 37signals and several other award-winning apps. HipByte continues to be on-top of their game and releasing updates left-and-right: RubyMotion stands at version 1.35, so an update just about every other week for the past year. They were able to ship iOS 6 support within 24 hours of the beta SDK being released, and I have no fears as to RubyMotion falling being or into deprecation.

And to be honest, my interpretation of RubyMotion's first birthday is a little entangled with what I've been up to this year. I've released more than what most psychologists probably consider a "reasonable" or "healthy" amount of open-source projects for RubyMotion. Plus, I wrote a book on the thing which has been read and enjoyed by way, way more folks than I had ever dreamed it would.

Folks still ask about "Rails for iOS," and if RubyMotion is helping create that. A year later, I think it's still unclear what even a "Rails for iOS" looks like or what problems it would solve. Mobile development as a whole, RubyMotion or not, is just getting to that age where we've seen enough design patterns emerge so we can start to make sense of how everything fits together; in other words, I don't think can tackle what "Rails for Mobile" looks like until we've figured out what a "Basecamp for Mobile" looks like (not to be taken literally).

At the end of the day, if you don't like Ruby, if dynamic typing and no compile-time hints are just not your thing, then RubyMotion won't change your mind. But if you do dig Ruby or Python, or just feel dissatisfied with Xcode and Objective-C, I'm bullish on the future of RubyMotion - the community, the product, and the company.

Let Me Tell You A Story

2013-04-24T00:00:00-07:00

Let Me Tell You A Story

I'm going to tell you about some stuff that worked for me. Some anecdotes and parables about how I got from point A to point B. It'll be light on hard data and analysis, and it'll probably hinge on one or two key but seemingly controversial decisions I made. I'm confident my self-crafted narrative will make you pull a one-eighty with regards to whatever it is you're doing.

I feel pretty strongly about these tidbits of advice, probably even a little attached to them. You see, all of my recent success is solely due to this simple collection of ideas. Although I'm distilling and funneling years of experience into a few quick bulletpoints, I promise they're the only thing that separates you and me.

And you'll read and nod and think, "Yeah, y'know, I can believe that, this guy sounds reasonable enough." And you'll Tweet it and Like it and Pin it and Snapchat it and everything else, because it's the kind of information you think everyone should know.

But then there will be others who disagree and think I'm absolutely full of it. These folks, in comments or in their own writing, will literally tell you to do the exact opposite of what I'm saying. They'll share their own stories and come to conclusions which are flat-out contradictory to mine, which just confuses the hell out of you.

Because in what universe can this other well-respected fellow and I both be correct? More practically, how in the world can you take either of us seriously and do something with our ideas?

You might defer to me, sending a message like, "Hey Clay, Other Person thinks you're wrong, what's up with that?" And I'll read through the rebuttal and make some "clarification" stating how that is a special case, while also slightly refining my own position to stay correct. But at the end of the day, it's basically a wishy-washy non-answer and I save face by maintaining that I'm still right.

A couple of days have pass, and where are you now? You've read some blog posts, sent out a few Tweets and Likes to grab the authors more followers, but you are basically back where you started. The social-media-information-entropy cycle.

So, anyway, what's my story?

That no ancedote will always hold true, no nugget of advice will always be set in stone, there will be counter-examples to every real-world observation, and that there are no platitudes (heh). Times and trends change; what's important is that you choose an idea quickly and be able to change your mind just as fast. Strong opinions, loosely held.

The Purple Crayon

2013-03-17T00:00:00-07:00

The Purple Crayon

There's this book, Harold and the Purple Crayon, that I just obsessed over as a kid.

It's the story of a boy named Harold and the namesake crayon, and how one night he decides to go on a moonlight stroll. But there's one small dilemma: he lacks a moon. So how does he solve his problem? Well, Harold simply goes and makes a moon using his crayon.

He continues to sketch himself into all sorts of adventures, like accidentally doodling an ocean and scribbling an emergency balloon mid-free fall. Harold keeps scratching his own itches and solving his (mostly self-concocted) problems using nothing more than the wax tool at his disposal and a bit of creativity.

The book has a simple premise, but something about it just kept me reading ad infinitum. I was stuck to it in that wonderful way kids can repeat something endlessly without any diminishing amusement or happiness.

Why? Because The Purple Crayon is, at its heart, a book about building things. About taking some idea in your head, something you want exist in the world, and making it happen. And by using the lowly crayon, rather than a computer or mechanical tools or complex math, it makes a kid feel that they really can create something. It's a glimpse of a world where your ideas are just one step shy of tangible.

But timing is everything: published in 1955, the book predates the web and all of personal computing by a couple of decades, and even beat plastic interlocking Legos by a couple of years. As a kid the 1950s, solving your own problems was decidedly a game of imagination over implementation: you could draw, write, and talk about what you would make all day long, but actually crafting something useful was pretty much left to the grown-ups. Then along came computers.

Coding democratized how we can solve our own problems, regardless of age. By the time I was toddling around, building websites in elementary school wasn't uncommon; when I got older, teenagers were starting companies in their dorm rooms that would grow into generation-defining entities.

So maybe the radical notion of a kid creating a moon, or at least space travel, isn't so far-fetched: it's just that we'd be using a Purple Keyboard. If you want something to exist, all you need might be a little leap from crayons to code.

Google Reader - A Product vs. A Symbol

2013-03-15T00:00:00-07:00

Google Reader: A Product vs. A Symbol

Google Reader, the product, died and should serve as a lesson in missed opportunities. But the loss of Google Reader, the symbol, should be grieved for and contemplated with many furrowed eyebrows.

Google Reader came out in 2005, before the iPhone, Android, and the ubiquity of smartphones. Before Twitter, Facebook, and Tumblr. It had a half-decade head start on Flipboard and Prismatic.

But it became a dinosaur. It was a desktop web product living in an age where we consume our content leaning around at bus stops or looking busy at awkward parties. Apps like Reeder and Press took the charge on nailing the user experience of reading feeds on-the-go; they grew, evolved, and established brands independent of and stronger than Google Reader. And they will live on after Reader's final breath.

Then came Flipboard, Prismatic, and all the other content discovery platforms that became smarter than just Google Reader in lipstick. They have impeccable design, strong brands, and are mainstream "things" in a way Google Reader never was (maybe partly due to Apple's high visibility endorsements). Despite building on top of the exact same web feed technologies as Reader, they created better browsing and recommendation experiences across the web, mobile, and the newborn content-havens of tablets.

Google Reader, the product, seems to be a textbook example of how an incumbent failed to head where the puck was going. But maybe where the puck went really isn't so great.

Google Reader is a symbol of a time just before the Yet-Another Rise Of The Wall Gardens; when the web looked to be on the verge of more semantic and open rather than proprietary; where information was becoming easily accessible and machine-readable instead of more locked up and fragmented.

Today, news and blog content is relatively open and parseable because of RSS and Google Reader's leverage, but all the recent social information about ourselves is locked behind protocols unique to each website and app. Google Reader did some damage to this cause of "openness", but it should remind us of a time before Twitter and Facebook swallowed our capacity for consumption and threw away the key.

I get why Google finally killed Reader. It was essentially free infrastructure and storage for an ecosystem of apps that generated more value (both financial and intangible) than the product itself. Google shouldn't be in the business of doing non-business, and it makes sense to turn off the lights. But it's another sign that we've entered a darker timeline in the history of the net, where information is becoming even more closed and out of reach.

Where The Puck Is Going

2013-03-01T00:00:00-08:00

Where The Puck Is Going

Mouse-and-keyboard are dead. Touch is dying. Post-touch is coming. Hyperbole? Maybe, but probably not.

See, about a year ago Gabe Newell talked about the future of gaming, and he not just illuminated my own cranial lightbulb but basically tossed a flash-bang grenade in its place:

[Mouse and keyboard were] stable for about 25 years. I think touch will be stable for about 10 years. I think post-touch, and we’ll be stable for a really long time — for another 25 years. I think touch will be this intermediate.

Maybe it was the way he phrased it, or maybe just what I had for breakfast that day, but by the end of that sentence everything seemed to make sense. The shift from mouse to touch to this thing Gabe calls "post-touch" appeared calculated, logical, and inevitable.

Why? In my mind, it clicked that that we're always inching closer to computing being "do what I really mean."

Before GUIs, computing was "type these commands and do what they state." That works, but you could easily type something different from what you actually want (as engineers are often reminded). And then after GUIs, we gained some more fidelity: something like moving a desktop folder meant "move the folder in the same direction as this mouse-device-thing." If you moved left, the folder went left.

Now, in the touch-era, it's more like "move the folder where my finger goes," without any mouse-indirection happening. But with post-touch, the status quo will be "move the folder where I'm looking" or "where I say"; and one day (as Kurzweilian as this sounds) it'll be "move it where I'm thinking." Or simply "move it."

And here we are, not even a full year after Gabe's talk, and the first post-touch products are already landing on Planet Earth: Glass, Myo, Leap Motion, Kinect, on and on. This stuff just creeps up on us; only six years ago this was the end-all-be-all of mobile "computing".

Touch devices cannibalized laptops and desktops, and you can bet that the new generation of post-touch products will gnaw away at smartphones and tablets. And it's exciting to think about what that future holds: what do things that replace our phones even look like? Will it be glasses? Or watches? Will it be made by Apple or Google, or a new player? Will it be as sci-fi as we imagine?

The abstractions between our intentions and how we execute them in computing are eroding. That's where the puck is going.

Why There Are No Game Console App Stores

2013-02-21T00:00:00-08:00

Why There Are No Game Console App Stores

At yesterday's Playstation 4 announcement, Sony kept hammering home how just unimaginably fantastic the PS4 is for developers. And they're right: the new x86 architecture is definitely a more familiar environment than the exotic Cell.

But the whole time I sat there thinking, "Developers, right, got it. So when are they going to announce the PS4 SDK and App Store for smaller guys?"

It never came. I watched all those folks come on stage and talk about how great the new Playstation is for them, and they even had Jonathan Blow show up to fill his almost obligatory place as indie ambassador, but they never did announce an App Store that normal programmers like me could take a shot at.

It wouldn't have been unexpected. When the Apple App Store was first announced in 2008, to me it seemed like a no-brainer for console makers to follow up with their own version. Five years later, Apple has hundreds of thousands of products in its store, and by far the most popular of which are...games. That's proof enough that consumers, non-traditional gamers especially, will download games from a marketplace in droves.

But it never happened on the consoles. Microsoft had an Indie Games store, but it was notoriously disregarded and under-promoted. Sony and Nintendo remained gardens with high, high walls. Why does this make sense for them?

The problem is money. Console hardware is generally sold at a loss or at cost; the producers make their profits from software. This includes fees and licensing from conventional boxed games, paid DLC and expansions, media and content sales, and (increasingly) advertising. Those are in a rough sort of descending order; boxed games are especially great for Microsoft et al because they're expensive and relatively hands-off.

But when you've got an App Stores, you've got a race to the bottom. Even if you artificially impose a price floor of something like $9.95, that's still $50 cheaper than the latest Halo. Given enough time, some developer will make a great looking and popular game at that low price point (or, more likely, for free) and lots of people will start to wonder, "Are Halo 5/KillZone/Zelda really worth $60?" And as soon as that idea is incepted into consumer's collective subconscious, all those big-ticket games start looking more like dinosaurs. The market becomes bimodal: either you're a massive AAA-budget game like Halo, or you're a low-cost indie game.

Console makers are already being faced with three new (and cheaper) developments in that direction: the OUYA, the Steam Box, and the lingering specter of Apple properly entering the space with an Apple TV SDK. These folks might not get giant Call of Duty-class exclusives, but they'll get more than enough independent games and apps to stay competitive on on their bottom line.

So what was the vibe I got from the PS4 announcement? More of the same. The market is evolving, and Microsoft, Sony, and Nintendo will eventually have to cannibalize themselves to keep up. And while Sony didn't announce anything radical yesterday, and Microsoft's plans are still unknown, both still have time to change the game.

How A Pull Request Rocked My World

2013-02-02T00:00:00-08:00

How A Pull Request Rocked My World

This is a story about Pull Request #2 and how it made me rethink my code. This isn't really a story about the code itself; it's about how even a small refactoring can multiply value and productivity. But hey, let's not get ahead of ourselves.

Long ago, there was some code in an iOS library called Formotion that looked like this:

if row.submit_button?
    make_submit_cell(row, cell)
elsif row.switchable?
    make_switch_cell(row, cell)
elsif row.checkable?
    make_check_cell(row, cell)
elsif row.editable?
    make_text_field(row, cell)
end

Basically, it configures this cell object based on properties of the row. That serpentine if/elsif chain did the trick and didn't seem alarmingly unreasonable at the time, so the code shipped with the first version of Formotion. It all worked out, the project got some watchers and star-ers, and folks generally had great feedback. All was well.

But then this little pull request appears a few days later.

I get an email about it, and am immediately excited because hey, someone liked my little project enough to contribute! So I command-click the link open in a new tab and have a look.

The request is labeled Refactoring & Multiline Text Type. So usually when someone comes up to you and says like, "Hey I did some refactoring, check it out," the implicit understanding is that the original thing just wasn't so hot. And about nine times out of ten you agree and know that it's true, but it is a little awkward when someone beats you to fixing it.

Anyway, I inhale whatever pride I have about my work and click the "Files Changed" tab to investigate. I take a gander, and basically what the request does is replace that big fat if/elsif block with this one line:

row.object.build_cell(cell)

Whoa, what is this new row.object? Well, elsewhere in the refactor, this line appeared:

@object = Formotion::RowType.for(type).new(self)

What's all this about? Turns out that the refactor took the various row configurations (switch, submit, check) and created new subclasses of Formotion::RowType for each: SwitchRow, SubmitRow, CheckRow, etc. In those objects, the build_cell method now dictates how the cell is configured, taking the place of the old make_submit_cell methods.

And that RowType.for() method? It actually does a little metaprogramming to grab the appropriate subclass:

# type == :switch or :submit etc
string = "#{type.to_s.downcase}_row".camelize
# string == 'SwitchRow', 'SubmitRow' etc
return Formotion::RowType.const_get(string)

So instead of some if tree and hard-coded methods, everything is dynamic and decided at run-time. You can reuse code with inheritance. Absolutely crazy. Brilliant.

All of this blew me away. Like this "@mordaroso" fellow strolled on up, cocked his knee skyward, and jettisoned his leg into the rickety wooden door that previously sheltered my mind.

So there I am, hunched over my laptop, eyebrows furrowed to the point where my forehead like folds in over itself, just stupefied by this code. And the ramifications, like how it allows for extensibility and plugins and testing and a generally more robust codebase, are just gushing into the void Fabio Kuhn exposed in said cranium.

With just that one refactor, the value of my little library had grown tremendously! If you wanted to make a plugin, there was no messy monkey-patching: simply create your new RowType subclass, like MyWidgetRow, and you're done. It just works.

Not a day goes by where I'm shin-deep in a project and don't think about what that pull request revealed: reorganizing your code (in the right way) can create cascading growth in productivity and value. In Formotion's case, that pattern of dynamic-class-lookup is now used in other parts of the codebase and allows for a project-wide plugin architecture. Big win all around. This sort of stuff really is worth being diligent about.

So thanks, Fabio, for blowing my mind.

Edit 2/3/2013 So a lot of folks drew attention to "You can reuse code with inheritance. Absolutely crazy. Brilliant." and took as equivalent to me saying "It's absolutely crazy and brilliant you can reuse code with inheritance." I get that both in- and especially out-of-context that's how it comes off, but it's not what I meant. It was sloppy and I should've been more careful in writing.

I meant it to come off more like "...everything is dynamic and decided at run-time, plus you get a great plugin architecture if you do some polymorphic tricks with these RowType objects. And all of these benefits came from just one simple refactoring. The power of small refactors is absolutely crazy. Brilliant." See my comment for more context.

Growing Old on Facebook

2012-12-22T00:00:00-08:00

Growing Old on Facebook

There's an entire generation where every photo, message, post, idea between adolescence and adulthood is cataloged on Facebook. Just click on the most recent picture and tap your left arrow key to see.

Wrinkles vanish, beards recede, and bodies contract and expand into the past. There's all the embarrassing haircuts, forgotten friends, parties, love, heartbreak, it's all there waiting to be rediscovered. New moments pile up every day, just itching for our future selves to find again.

And more than the photos, there's also the way we talked, the jokes we made, all the effortless things that were once second-nature but now look a bit alien. Things we factually know we said, but for the life of us can't figure out how it came out of our mouths. Maybe for other generations these were glimpsed in diary scraps or old letters, but now it's just...there, on Facebook, digitally frozen in time.

You can message someone you haven't spoken with in years, and yet it visually flows right under some unimaginably unrelated conversation from 2007. And when you realize that exact numerical gap between the years, it stings a little. Reading how you've changed, how they've changed, and thinking about everything that didn't happen in-between.

These experiences and emotions are unprecedented. We're on the precipice of something new and unknown, but undoubtedly permanent, in the human condition. It was never this easy or this obvious to see how we've grown, or how our friends came and went out of our lives. We can reconstruct our past and evolution with such incredible detail, but at the same time there's just a tinge of sadness...

It might not forever be on Facebook or Twitter or whatever else becomes popular, but the progress of the internet will not cease. These pristine reflections of our former selves will live on in the tombs of archived data; they will outlive us.

Me, 2006, via Facebook

Web Views Are Green Screen

2012-12-19T00:00:00-08:00

Web Views Are Green Screen

That's the set of Lord of the Rings, taken around twelve years ago. Even a decade later, these films have hardly aged a day, mainly due to what is evident from this photo: beautifully designed set pieces. The relatively early computer graphics of the time are (with the exception of Gollum) rarely front-and-center, as the production opted for a real-life, intricately crafted world using as little green screen as possible.

And a decade later, you just don't find this kind of movie set anymore. Instead, we get last two Star Wars prequels, filmed in giant green and blue boxes.

In moderation, green screen works wonderfully, drawing us further into the film's world and breathing life into the impossible; at its worst, digital meddling is jarring and actually takes us out of the experience, making us wonder, "Oh yeah, that's not real." And then we're no longer thinking about the characters or the story: we're thinking about the fact that this is a movie, and those are computer graphics.

The same holds true for the web views we often embed in mobile apps: executed when necessary and with great skill, they can actually create a better user experience. But when we fudge them up, as we often do in these nascent days of mobile development, it breaks the illusion and users are left thinking, "Hmm, why doesn't this bit work like everything else?" And then our users aren't thinking about their original purpose of opening the app: they're considering the technology and pondering why it doesn't feel quite right.

George Lucas and many other filmmakers embraced the digital, green-screen-everything revolution in part because it meant a less cumbersome and more flexible process: no rolls of film to worry about, and if you're not sure how to design a set right now then it can all be changed in post-production. Sound familiar? Sort of like, "No Objective-C or Java to compile! We can change at any time from the server!"

The temptation with web views is our ability to change things without an additional app approval cycle, and that ability can be a practical requirement or strategic advantage. But it comes at the risk of making that part of the product feel unnatural, especially given how precisely a web view needs to be programmed to make it look-and-feel native. And the more upfront your app is with its web views, the more obvious it will probably become. Just like bad green screen effects.

Those are the risks...but there is also another way. Pixar films are entirely computer-generated, which means nothing looks out-of-place and our brains aren't busy thinking, "This part is real but that bit over there is fake." This is why WebOS was so promising: its third-party apps felt natural because, despite being just HTML and CSS, everything else the user interacted with on the device was also a just web page! There wasn't a destination between "web" and "native": it was all the same.

Maybe that's why it's such a tragedy that WebOS didn't take off, or that Google has pushed Android onto millions of devices instead of a mobile version of Chrome OS. For one reason or another, web-browser operating systems just haven't taken off, and that means native software will continue to be a better solution when forming the ideal user experience. Just like hand-crafting films will yield more timeless results than giant green boxes.

At the end of the day, after the lights turn off and the actors have left, all the special effects in the world won't prevent you from making a bad movie. Whether we're producing motion pictures or mobile apps, we're telling stories, trying to create something people care about with nothing but our minds and our hands. And if our core idea just doesn't work, then no amount of digital sugar-coating will save it.

We're Better At Design, And That's Not Good

2012-12-15T00:00:00-08:00

We're Better At Design, And That's Not Good

Everyone is getting frighteningly good at visual design. The skills dispersed, our hardware improved, pixels shrank, and big companies began putting muscle behind their Dribbble stars. Every year, without fail: more, better, and easier. The last decade had some missteps, but overall a greater proportion of software just got really damn good-looking. And that kind of worries me a little.

It worries me that really good visual design is becoming commonplace. It used to be that you could just glance at a website and get a quick feel for its quality and recency just from its visual identity; look at Facebook versus Myspace, or Svbtle versus Wordpress. Visual design can add important interaction cues and serve a greater purpose than eye candy, but its role in branding shouldn't be underestimated.

And over the past few months, I noticed most newborn products look fantastic from day one. It could be from Bootstrap, or readymade iOS templates, or a better freelancer they found on Scoutzie, or 99Designs, or whatever; there are now a myriad of methods you can use to launch your service and make it look great for cheap or even free.

So what's wrong with that? The problem is we judge books by their covers. We're more likely to pick the prettiest object up first.

I know someone might shout, "No! The important part isn't the visuals, it's all about the interactions and the core product!" And that's exactly right; but to get a feel for those deeper aspects you need to spend time with it, and we usually don't have that time. People decide whether the phone they might buy sucks based on a few minutes of noodling, and that impression is dominated by the graphics and flashy animations. And consider the app economy without free trials, where the only thing you see in search results is a few carefully picked screenshots.

When everything moves toward beautiful, it chips away at our "product survival" instinct and makes it harder for us to tell the gold from the crap. We could be looking at a dangerous, privacy-invasive service and still have some trust because it's wrapped in lickable buttons and subtle gradients. Or you could be walking down the grocery aisle and pick an unhealthy cereal basically made of high-fructose corn syrup because the box made good use of whitespace and a bold sans-serif font. What was once our compass for quality now points in every direction.

That doesn't mean we should drop everything and make plain, styleless software again. Instead, we need to remember it's an arms race: you use TypeKit, they license directly; you spend $5,000 on an icon, they hire an entire consulting firm. More impressive visuals will offer diminishing returns against competition.

So what's the solution? Just make sure your product doesn't look terrible, and then move on. Build the things people care about, talk to your customers, and iterate. There is no silver, reflective, radial-gradient bullet to success.

Writing a Programming Book

2012-12-12T00:00:00-08:00

Writing a Programming Book

It's barely past midnight on Christmas, and there's a book on my lap. Its black glossy cover smears with every brush of my fingers. Front and center, the lone graphic is half of a sliced, juicy grapefruit. That “new book” smell eases from the unworn pages. The book is "Beginning iPhone Development" by Dave Mark and Jeff LaMarche, and it changed everything for me.

So here I am years later, just finished writing my own iOS book. It's hard not to wonder if there's an aspiring programmer who might connect with my work like I did with Dave and Jeff's. That maybe my little RubyMotion book might show them, "Yeah, it really is this easy to build something cool"; but then again, almost every other book I read failed to do that.

There are as many different ways to write a programming book as there are programmers. There are those reference tomes, the kinds of things that sputter dust when you manage to wrangle them onto the desk. Then there's the cookbooks, textbooks, the career guides, the list goes on. But growing up I collected dozens of the venerable "Getting Started" genre, and that's what I wanted to do for RubyMotion.

Writing that kind of introduction is tricky. You risk stonewalling your readers to the point where they flip the table and walk away, never giving the technology the chance you believe it deserves. In my experience, those books usually have an authoritative or even aloof tone, and focus heavily on demonstrating "the right way." But the right way to engineer a project might be the wrong way to get excited about it.

I made my priority to get something cool, but simple, on the reader's screen as fast as possible, and then worry about cleaning up any mess a little later. For example, iOS books usually start off with how to use Interface Builder or setting up UIViewControllers, but that's just so much overhead to getting anything interesting on the screen. I bucked tradition and began with code I'd never use in production: adding blue boxes straight on the app's UIWindow. It's a bit dirty, but then we can quickly jump into buttons, animations, text boxes, and really start to make fun apps.

Technical reviewers noted that exact decision, and then expressed their delight at how well it actually worked. And to me, that's what a "Getting Started" book is about: here's the bare-minimum, and now here's cool stuff we can do with that. As long as you keep that thesis in mind, the rest of the writing is just filling in gaps.

So, if you're in the market to very quickly become up-to-speed on iOS development, then join me in making cool projects with RubyMotion: iOS Development With Ruby. Or if you think this is all a rubbish idea, ping me on Twitter.

So, What Do You Do All Day?

2012-12-02T00:00:00-08:00

"So, what do you do all day?"

There's the sounds. Or, more often, the lack of sound. No crescendos or variation, but just intermittent spurts of either furious clicking or — nothing at all. Repeating, hundreds of times each day. From the repetitive, almost rhythmic tapping to —. Just an abrupt, knife-like silence.

It's uncomfortable, struggling silence. It could be any mix of confusion, frustration, or just bewilderment, lasting longer than any given torrent of keyboard noise. And, as trite as this sounds, it really can be deafening. The longer it grows, well, the harder it is to overcome.

And in those lingering silences, I'll wait. Probably a little hunched, maybe cradling my chin in one contortion or another, but still silent. Get up, walk around, make some tea, all trying to coax a little inspiration out of my subconscious.

We romanticize our authors and envision the constant clicking of their typewriters, but I like to imagine they had their quieter moments too. That it wasn't always so perfect and picturesque, but that it was hard and took work. That sometimes their initial excitement extinguished...but at the end of the day it was rekindled.

And eventually, the silence does end. Whether by a genuine solution or by the brute, angry force of my own frustration, the rapid clicking resumes. And somehow, the sum of all these clicks and all their gaps creates something I set out to make.

How It Feels To Build

2012-11-25T00:00:00-08:00

How It Feels To Build

It starts with an idea, and then we plunge an arm into the nothingness. And one tightened fist at a time, we pull from it any material we can. Scoop by scoop, it slowly takes shape. And the more of our creation we see, however nascent or crude, the quicker our pace; our designs multiply and ambitions soar until we're racing, and our own bodies struggle to fly alongside our imaginations, and from a soup of nothing except ourselves, we build.

We build skyscrapers and cathedrals. Rockets and subways. All like lightning from our minds, striking down through our fingertips. Not measured in years or months, but hours and days. What was once impossible is now quaint, and what is inconceivable today will soon be common. That's why we keep chasing and breathlessly rushing on to the next one.

But for a small moment, we stand toes in the sand and hesitate, looking back at what we built before. A lucky few of our structures might still be illuminated in the night, faint beacons of our past success. But no, so much of it erodes...standing empty and forgotten. So much thought, so much effort, so much love and care left derelict and crumbling. It makes you wonder why we should even push onward.

Because if you stop for too long, you can hear the echoes. Of the arguments and turmoil that went into constructing each one. Of what, and who, we lost along the way. And what it all used to mean to us, how exciting it was at the start. And really, that's what'll take it out of you: that it was actually us that didn't work out. That we rose too high, dallied too long, or even just chose the wrong thing to make. That it was our fault.

And for that moment, it's absolutely crippling. But, right before we succumb and fade away, we remember all those who came before us. No different than you and me, they hit the same walls, saw the same wreckage, and felt just as frozen. They too were ready to abandon it all, but instead they changed. They broke loose, and chose to live with and learn from their mistakes. It never got easier nor did it ever feel quite the same, but when it finally did work out...it was just electric.

So we remember our past and advance cautiously, one step at a time. Until suddenly, seduced by the next hot spark of inspiration, we run. And we hope that what we build this time might be different.

Billboards Are Like Facebook

2012-11-10T00:00:00-08:00

Billboards Are Like Facebook

Just a little over a month ago, Facebook started pushing its "*X* Is Like Facebook" campaign. It started with the infamous Chairs video, and they've kept it up with some other extended metaphors. Say what you want about the campaign's execution, but it's to trying something seemingly off-beat and bold in its messaging. Really, what other company has tried to explicitly associate its product with solving existential loneliness?

This is Facebook's self-description: "Facebook's mission is to give people the power to share and make the world more open and connected."

Many folks at Facebook, from top to bottom, believe that on a deep level. It's an admirable mission. But to operate, Facebook also needs to be a company. This gives it a strange identity crisis; even Zuck's letter to investors begins, "Facebook was not originally created to be a company."

This is my Newsfeed earlier today, colored red for ads and blue for non-ads. If you break red versus blue down into percentages, it's 80% ads; if you want to count the navigation bar and side-navigation, then 54% advertising.

Examinations of Google like this have been done and discussed exhaustively. The takeaway from this isn't "Facebook is 80% ads." Instead, it just shows how much Facebook paid promotional content has above-the-fold.

On one level, this does help me "connect" because the ads are almost always tied to one of my friends. My buddy Dylan likes Revolights; that could be insightful to me, so their sponsored story appears in my feed.

I'm not saying this is a bad way of advertising. Anecdotally, I have probably clicked or liked more things through Facebook's promoted posts than Google searches. And I think user-promoted posts are a great way for people to surface content that they care a lot about.

But really, advertising at all on Facebook leaves a funky taste in my mouth.

Facebook is ostensibly about making the world "more open and connected," but half the time I visit the site it's dominated by paid promotions. And I get it, the company needs to make money, there's nothing wrong with that in-and-of-itself.

But then Facebook creates a video about how, "[The universe] is vast, and dark, and makes us wonder if we are alone." That's a powerful statement about existence, and it comes from a tech company. But it is a company nonetheless, and at the end of the day we're being sold something.

What bothers me is how we're okay with this; that the tragedy of the video is the comical absurdity of the "Chair" analogy and not the deeper tragedy that any company is trying to connect with us like this at all. How one minute we're being pitched about Facebook addressing the human condition, and the next we're advertised to about Farmville. It's a schizophrenic experience straight out of Infinite Jest.

And you know what else? There's this meta-cognitive dissonance where I know all of this, but right after I finish writing I'm actually going to go post about it on Facebook. And if you feel like participating in the absurdity, there's also a Like button at the bottom of the page.

☆ Give A Damn

2012-10-27T00:00:00-07:00

☆ Give A Damn

I want to tell you about The Kid. I met The Kid a few years ago, right out of high school. He had shipped some popular iPhone apps, made a few websites, had a bright future.

I don't know how it started, but The Kid really believed in "Move Fast and Break Things". Ship-First-Questions-Later sort of guy. It made sense to him: the product was the purpose, and the code was a means to an end. He loved the things he could build, but wasn't big on the process.

So The Kid carried on and built a lot of cool stuff. I saw some of the code, and it ain't pretty. But the end result still worked fine. And it got him pretty far, too. He'd flaunt these creations and eyes would go wide. It all looked impressive. He was young, sure, but who wouldn't want to grab that talent while it was cheap?

The Kid started working. He was famous for shipping new features that the users loved. And damn could he do it fast! Usually from idea to production in just a few days. Hundreds of lines of code in an afternoon, I kid you not. Lots of pats on his back, I'm sure. It all seemed to be working out for him, living the good life.

And then things changed. I saw The Kid just about a year ago, working feverishly on a complete product redesign. Lots of new code, not a lot of time to think about it. Just him on the project, no second opinions or supervision. As with all redesigns, feature requests piled up at the pace of a bad game of Tetris. But who was The Kid to say no? Sleepless nights later, The Kid emerged with something. At first glance it looked great; even I couldn't believe it came together so quickly. Champion effort on his part, right?

But here's the rub: delve beneath the surface and it was just too buggy. And these weren't just sloppy edge-case bugs, they were "What idiot do we need to fire?"-class problems. The redesign was shelved and rewritten again without The Kid.

The Kid didn't lose his job, but I could tell it hurt him like hell. Because to programmers like us, what is our work but extensions of ourselves? What did this disaster say about The Kid?

He laid low for a bit, ashamed of what he had done. Moving fast and breaking things had gotten him far, but now he had finally broken too much. Kind of world-shattering to him, I guess. It was a dark place for The Kid.

And that's when I heard The Kid grew up. You could say he became The Guy, The Dude, whatever; the point is he had a change of heart. He started to realize shipping might not be everything. His screwup was a loud wakeup call that he needed to change his scene.

And so (and this is all hearsay, mind you) The Kid started caring about his code. Not just caring, but really giving a damn about it. And not because it was a means to an end, but for the sole sake of caring about it. "Code is more than just a tool," I heard he said. "It's our craft. It's our muscle. And we need to train it. Chop wood. Carry water. Code."

I heard all sorts of wild rumors. That The Kid started using "best practices" in all his Google searches. That he started learning the deep internals of the beasts he wrangled, whether it were Rails or iOS or whatever, just for the intellectual pleasure of it all. Code was no longer a beast to be tamed; it was a creature, to be both studied and admired. He even tried to teach others the error of his old ways. Wild stuff, right?

Did The Kid completely abandon his old ways? Well, apparently not. He said something about how there's a, "time and place for everything." That sometimes we need to ship fast and will break things. But if we take all the other time we have and put it to good use by really learning and crafting our code, we'll break less.

Kind of a crazy change, but I'd believe it. I thought a lot of things about The Kid when I met him a years ago, but I didn't think he was stupid. He grew and evolved as we all do. And he's probably not even done yet, wherever he is. But next time you need to move fast, take a deep breath before taking the dive. Remember The Kid in all of us.

Don't Say Startup

2012-10-09T00:00:00-07:00

Don't Say Startup

The word "startup" gets thrown around a lot. Mainstream media calls Twitter and any other pre-IPO company a startup, PG says startups are businesses that grow fast, and Peter Thiel says startups are all about unique business models. That all sounds pretty reasonable, right?

But at any given Silicon Valley event, you have some folks referring to all variety of what they're working on as "startups". It could be their one-man iPhone app, a newborn hackathon project, or even the legendary stealth-mode project. I know I'm guilty of it too.

So I've made a new rule: unless you've raised money, are bringing in substantial revenue, or have a sizable active user base, don't call whatever you're building a startup. I'm not trying to belittle or be a jerk; I'm hoping to cut everyone some slack.

Every time you introduce your product to someone as a startup, you set an expectation for where the conversation is going next: your funding, revenue, user base, that sort of talk. That might be appropriate, but if you're not at that stage where it's a proper startup then you'll inevitably fail to meet those expectations. And that sucks, because you lose a little social capital each time that happens.

You've probably been on the other side of this conversation: someone tells you they're doing a startup, you ask for details, and it turns out to be pretty nascent. Kind of a let down, right? It probably would have ended better if they had avoided the word "startup".

Instead, focus on what you're building and resist putting a label on it. Say something like, "We're building x" or "We just launched our product, y." This should make sense: your product is what people care about, whether or not your venture really is a startup. Or if you're not quite ready to reveal what you're doing, then a simple "I'm working on my own thing right now," is satisfactory.

The more we throw around the word "startup", the less of an impact it has when we actually want it to matter. So do yourself and the community a favor: drop it only once you mean it.

RubyMotion Metaprogramming

2012-09-23T00:00:00-07:00

RubyMotion Metaprogramming

Metaprogramming is pretty neat. While there is an awfully fun mad-scientist feeling I get when my code creates and redefines methods and entire classes at runtime, metaprogramming is not for every programmer or every project. But when it is able to make your life easier, I'm very thankful it can be wrangled Ruby.

Now, conventional Ruby's flexibility and really-everything-can-change-at-runtime mentality come at a high cost with respect to performance; thankfully, RubyMotion isn't your father's Ruby. Its language is a compiled variant of Ruby that implements most of the standard library but without all of the slow interpreted cruft. Basically, this means we can't use eval, but RubyMotion still supports most of desktop Ruby's metaprogramming functions (we'll get to specifics soon, I promise).

Is it a huge deal to have this ability on iOS? The short answer is yes, assuming it floats your boat. Despite being built on top of good-ole C, Objective-C actually has some neat metaprogramming functionality tucked away in objc/runtime.h; however, it's not a first-class part of the language and isn't a go-to tool like the Ruby community has made method_missing or define_method.

So if you've always wanted more "meta" in your iOS code, let's jump into what RubyMotion does and does not support (hint: it supports everything important). In the meantime, I'll try to keep it real and give examples from actual code that I've written.

`send`

I don't know if you can count this as proper metaprogramming, but it does reveal one of the fundamentals of Ruby: methods can be invoked dynamically using just strings. Why is that a big deal? We can take a lot of if/elsif code and use send to simplify it into one call like so:

def tableView(tableView, didSelectRowAtIndexPath:indexPath)
    menu_row = self.menu_items[indexPath.row]
    # => 'profile'
    self.send("open_#{menu_row}")
end

def open_profile; #...; end

def open_messages; #...; end

def open_feed; # ...; end

Now when we add more rows to self.menu_items, we don't have to mess with didSelectRowAtIndexPath: at all! It scales with the rest of our product. Neat, right?

`define_method`

Since we can invoke methods dynamically, wouldn't it be nice if we could add them just the same? Well, you're in luck because define_method was just added to RubyMotion. With it, we can define (or re-define) a methods using a string and a block.

We can write part of the canonical has_one method from ActiveRecord in RubyMotion like so:

class Profile

  # EX: has_one :user
  def self.has_one(name)
    klass = make_klass_from_name(name)
    # EX: => User

    # Effect: (a_profile.user) === User.first(conditions: "profile_id = 4")
    define_method("#{name}") do
      klass.first(conditions: "#{self.class.stringify}_id = #{self.id}")
    end

    # Effect: (a_profile.user = a_user) === a_user.profile_id = 4
    define_method("#{name}=") do |value|
      value.send("#{self.class.stringify}_id=", self.id)
      value.save
      value
    end
  end

  def self.stringify; "profile"; end
end

Make sense? One confusing part might be that define_method appears to jump around in scope: when we define #{name}, our definition uses both the local klass variable from has_one and a reference to self.class. This is because define_method uses a normal Ruby block for its method definition, and thus is a proper closure. In less fancy words, it'll snatch local variables assigned outside of define_method and keep a reference to them in the definition for when the new function is actually called; everything else is evaluated in the scope of an instance of our Profile class.

Using generic variables like name and klass can make things hard to grok, so use define_method with caution. It can be incredibly powerful and speed up repetitive tasks, but can also make things a headache to debug.

You might have noticed we used a parameter in our block for #{name}=, which tells the definition that our function takes one argument. You might find a circumstance where you want to play with default values or pass a &block to a dynamically added method; for those, the normal do/end blocks will not suffice. Instead, use the stubby-lambda syntax, which allows every convention of a normal function definition:

# Stubby lambda: ->
define_method "#{name}_with_default", ->(arg1 = :my_arg, *args, &block) do
  p "arg1 #{arg1} args #{args.inspect}"
  block.call
end

`define_singleton_method`

Sometimes you want to add a method to a class, not an instance. For this, we use define_singleton_method, which functions just like define_method except acting on the class in question:

class Sayer
  def self.shouts(*words)
    words.each do |word|
      define_singleton_method "shout_#{word}" do
        p word.upcase
      end
    end
  end

  shouts :hello, :goodbye
end

Sayer.shout_hello
=> HELLO
Sayer.shout_goodbye
=> GOODBYE

For a more practical example, you might check out this gist by @senthilnambi.

`alias_method`

Pretty nifty method to copy current method definitions into a differently named function. Sometimes you do this to just change the function name, but other times you can use it to preserve an existing implementation and make use of it later.

class UIView
  alias_method :background_color, :backgroundColor
end

`instance_eval`

instance_eval shipped with the original version of RubyMotion and is particularly useful in the creation of DSLs. Any block you pass to it will be evaluated in the context of the object it is invoked on. Lots of big words in there, so check this out:

table_cell.addSubview(special_subview)

# alias_method is private, so have to use #send
table_cell.class.send(:alias_method, :old_layoutSubviews, :layoutSubviews)

table_cell.instance_eval do
  def layoutSubviews
    # nifty trick, right?
    old_layoutSubviews

    _special_subview = viewWithTag(SPECIAL_SUBVIEW_TAG)
    _special_subview.frame = #...
  end
end

Normally, if we wanted to add custom behavior in layoutSubviews we'd have to create a custom subclass. This might be appropriate, but in Formotion's case we often needed to apply changes to just one instance of a view.

instance_eval is especially powerful in creating DSLs. Usually DSLs will take a block supplied by the user and simply run instance_eval on it, like so:

class UIViewDSL
  def initialize(view, block)
    @view = view
    instance_eval(&block)
  end

  def background_color(color)
    @view.backgroundColor = UIColor.send("#{color}Color")
  end

  def frame(frame)
    @view.frame = frame
  end
end

def create_view(&block)
  view = UIView.alloc.initWithFrame CGRectZero
  UIViewDSL.new(view, block)
end

a_view = create_view do
  background_color :black
  frame [[0, 10], [100, 100]]
end

Note that because our &block in create_view is passed around, background_color and frame are actually invoking methods of UIViewDSL.

`class_eval`

So if instance_eval applies to an instance, how do we cascade changes to all instances? We can use class_eval on a Class and apply the same technique:

Fixnum.class_eval do
  def random
    rand(self)
  end
end

3.random
=> 1

`module_eval`

You get the idea.

`const_get`

const_get is how we grab classes, modules, and constants at runtime. The object on which we invoke const_get determines the scope of the results we get back; for example, grabbing a User class from a Facebook module versus a Twitter module.

I use this often to wrap the LongPrefixedObjectiveCConstants as symbols:

# EX const_int_get("UIReturnKey", :done) => UIReturnKeyDone == 9
def const_int_get(base, value)
  return value if value.is_a? Numeric
  value = value.to_s.camelize
  Kernel.const_get("#{base}#{value}")
end

# from the BubbleWrap/Camera source:
# @options[:source_type] is like :photo_library or :camera
const_int_get("UIImagePickerControllerSourceType", @options[:source_type])

The one downside to using const_get in RubyMotion is that all of the Objective-C integer constants must exist in your source code to get added at compile-time. For a good example, check the source to BubbleWrap's Camera module.

`const_defined?`

const_get will throw an error if we try to grab an undefined constant, so it might be a swell idea to run some type of safety check beforehand. const_defined? lets us do just that:

Kernel.const_defined? "UIView"
=> true
Kernel.const_defined? "UIAwesomeView"
=> false

`const_set`

If we can get and check for constants, then all that's left is to create them. Again, mind the scope at which you call this function; so far we've been using Kernel, which is the top-level scope, but you could accidentally override existing constants or classes.

Let's say we wanted to create a new subclass at runtime. That sounds pretty crazy, but call me maybe?

color = "green"
color_klass_str = "UI#{color.capitalize}View"
# => UIGreenView

if not Object.const_defined? color_klass_str
  Object.const_set color_klass_str, Class.new(UIView)
end

klass = Object.const_get color_klass_str

klass.ancestors
# => [UIGreenView, UIView, UIResponder, NSObject, Kernel]

klass.send(:define_method, "backgroundColor") do
  UIColor.send("#{color}Color")
end
# By default, our UIGreenViews will have green background colors.

And if you don't get goosebumps doing that, I don't know what thrills you.

What's not supported?

To my knowledge, only the string-based eval methods (which rely on an full-blown interpreter) and Bindings are not available in RubyMotion. With the recent addition of define_method, I'm even more excited to see what else comes out of the RubyMotion community.

If you have any questions or qualms, continue the discussion on Hacker News or send me a tweet.

What Excites Me About RubyMotion

2012-09-14T00:00:00-07:00

What Excites Me About RubyMotion

RubyMotion made a splash when it came out four months ago. But summer wanes and winter is coming, so where are we now? By far, the most exciting change has been the growth of the community and what it's cooking.

From my perspective, RubyMotion libraries have gone through three waves. The first are very thin shortcuts for the original Objective-C functions; mostly, these are to reduce keystrokes and add a bit of Ruby flair. They're low-hanging fruit, and BubbleWrap has them in spades:

# NSSearchPathForDirectoriesInDomains...
App.documents_path

# NSBundle.mainBundle.resourcePath
App.resources_path

# NSNotificationCenter.defaultCenter
App.notification_center

These are nifty, but not a huge win over Objective-C; we get a little more unique with the second wave of new libraries. These abstract entire classes and frameworks into idiomatic Ruby wrappers. A lot of the vestigial Objective-C paradigms (delegation, protocols, selectors) don't make sense in Ruby and having a layer of abstraction hiding these details is a step in the right direction. For example, check out how BubbleWrap handles using the front-facing camera:

BW::Device.camera.front.picture do |result|
  p result[:original_image]
end

Clean, right? No dealing with UIImagePickerController or its protocol. Twittermotion uses a similar structure for composing a tweet with the iOS native interface:

Twitter::Composer.compose(tweet: 'Hello RubyMotion!', urls: ["http://clayallsopp.com"]) do |composer|
  if composer.cancelled?
    # user didnt sent the tweet
  elsif composer.done?
    # user sent the tweet
  end
end

Most of these wrappers are probably implementable in Objective-C, but they are tremendously easier to grok at-a-glance for Rubyists and any others just beginning iOS development.

At this point, it would be understandable if you still didn't think RubyMotion merited its $200 price tag. But before you close the tab and move on, there's one more wave of RubyMotion libraries: those that invent completely new metaphors for development.

What do I mean by new metaphors? These libraries do more than just wrap the standard iOS SDK: they turn it on its head and allow us to express ourselves in novel ways. Take Teacup, which lets us separate our layout and style logic into Stylesheet objects:

Teacup::Stylesheet.new(:menu) do
  style :root,
    landscape: true

  style :menu_item,
    left:   0,
    top:    0,
    width:  160,
    height: 160,
    landscape: {
      width: 240  # make it wide in landscape view
    },
    title: 'Menu'
end

class MenuController < UIViewController
  stylesheet :menu

  layout :root do
    @menu_item = subview(UILabel, :menu_item)
  end
end

Instead of spending dozens of lines doing frame calculations and positions in our controllers, we can separate these parameters into a smarter object. Given how thick iOS controllers can become if unmanaged, it's a major boon for when you need programmatic control of your views. Plus, since Stylesheets are normal Ruby objects, perhaps we could dynamically create them from a server configuration or let the user tweak them to as preferred.

Formotion is another "new metaphor" library; it allows you to declaratively construct complex and interactive views. Although you can create standalone form-based layouts like the Settings and Contacts apps, views can also be constructed using just a model's definition. This lets us prototype screens in an application's flow incredibly quickly, like this little example:

class User
  include Formotion::Formable

  form_property :name, :string
  form_property :score, :number, transform: lambda { |value| value.to_i }

  form_property :team, :picker, items: ["Red", "Blue", "Green"]

  form_title "Edit User"
end

user = User.new("Harry", 100, "Green")
controller = Formotion::FormableController.alloc.initWithModel(user)
self.navigationController << controller

Pretty incredible that I can construct a non-trivial UI with only what, a dozen lines of code?

And these libraries are just the start of a wholly new way of looking at how we structure and develop mobile apps. This is why I keep pushing myself to create with RubyMotion, as to re-think the status quo of the past five years. iOS development has come a long way since 2008 and there's absolutely nothing wrong about the current APIs, but Ruby seems to help developers frame tasks in new a new and often revealing light.

So is it worth the price tag? For some, still maybe not quite yet. But what just the past few months have shown is a window into something fresh. And to me, that's just plain exciting.

This was adapted from a talk I gave at an SF Bay RubyMotion Meetup

It's Just X Through Y While Z

2012-08-27T00:00:00-07:00

It's Just X Through Y While Z

Every few days, I'll see an idea dismissed on Hacker News because of its simplicity. Typically, engineers see some new product and state that it's just some chain of obvious technical steps.

For example, Dropbox was just "an FTP account, [mounted] locally with curlftpfs, [using] SVN or CVS on the mounted filesystem." Heroku was just git hosted on AWS with a post-commit hook to boot a Rails server. Square was just a magnetic reader using the headphone jack. Easy stuff, right?

In fact, almost every successful product which can be reduced "basic" steps. Perhaps there are so few counter-examples because products with irreducible innovations are rarely executed as well as their seemingly straightforward counterparts. It's hard to simultaneously come up with raw, astounding technology and still ship a great customer experience. Usually it is only the next generation of companies that can take the technology and execute on a succcessful product.

The famous example is Xerox PARC: even though the Alto and the Star featured groundbreaking innovations, it would be years until Apple and others successfully brought PARC's research to the masses. This is why I'm skeptical of Google's ability to successfully commercialize its self-driving car; instead, I'd bet on a future entity that takes Google's work and makes incremental but key improvements. Of course, such an effort will inevitably be dismissed as, "just Google's tech but with x."

It's peculiar that we are so eager to dismiss ideas in this way, and yet it's apparently difficult to do the inverse. Out of habit or hubris, we miss the unconscious steps we take everyday to solve our technological pains. And when we do notice some minor repititions in our work, we resort to equally small engineering improvements like scripts and increased automation.

Such solutions are great and vital to building a product, but we fail to see the macro-problems that really hinder our progress: CRUD development sucks, real-time sucks, payments suck, the list of problems we've already realized goes on and on. They sound obvious now, but such problems exist for years before someone stumbles upon the Better Way. What else belongs on this list hiding right under our noses?

Just the other day, I read about how watching Netflix abroad isn't "terribly difficult." Next time you see that sort of list, it wouldn't be a bad idea to take note of the opportunity before you. And better yet, you should give pause and wonder if there's a greater problem afoot than just taking x and going through y while z.

Mixing Objective-C and Ruby

2012-08-24T00:00:00-07:00

Mixing Objective-C and Ruby

I've written a lot about RubyMotion, but one aspect I haven't touched on is how you can mix-and-match Objective-C and Ruby. That means you can use Objective-C code in RubyMotion projects and use Ruby code in traditional Objective-C apps. That sounds like black-magic, so let's walk through some quick examples.

Objective-C in Ruby

Most iOS developers have a deep backlog of existing code, and porting it to RubyMotion by hand is a pain. Luckily, we can just add the compiled Objective-C to our shiny new RubyMotion apps.

Imagine we have a CYAlert class we want to use in our RubyMotion app; it's pretty short and looks something like this:

// CYAlert.h
#import <UIKit/UIKit.h>

@interface CYAlert : NSObject

+ (void)show;

@end

// CYAlert.m
#import "CYAlert.h"

@implementation CYAlert

+ (void)show {
    UIAlertView *alert = [[UIAlertView alloc] init];
    alert.title = @"This is Objective-C";
    alert.message = @"Mixing and matching!";
    [alert addButtonWithTitle:@"OK"];
    [alert show];
    [alert release];
}

@end

To use this in our RubyMotion app, we just put both files inside a folder (such as ./vendor/CYAlert) and tell RubyMotion to also build that folder using vendor_project in the Rakefile:

Motion::Project::App.setup do |app|
  # Use `rake config' to see complete project settings.
  app.name = 'MixingExample'

  # ./vendor/CYAlert contains CYAlert.h and CYAlert.m
  app.vendor_project('vendor/CYAlert', :static)
end

Now in our AppDelegate, we can use our CYAlert as expected:

class AppDelegate
  def application(application, didFinishLaunchingWithOptions:launchOptions)
    CYAlert.show
    true
  end
end

Pretty neat, huh? RubyMotion knows how to build two types of Objective-C codebases: :static as shown above and :xcode, which is exactly what it sounds like. You can read more about the options for both in the RubyMotion docs.

CocoaPods

Since RubyMotion can build any old Xcode project, using the existing CocoaPods system doesn't require a huge leap of imagination. The motion-cocoapods gem adds a nice DSL to automate the process in your Rakefile, like so:

...
require 'motion-cocoapods'

Motion::Project::App.setup do |app|
  # ...
  app.pods do
    pod 'JSONKit'
  end
end

Ruby in Objective-C

Compiling to a common bytecode is a two-way street: we can also bundle Ruby classes into Objective-C projects. That sounds wild, right? Imagine we re-implemented our CYAlert in Ruby, like so:

# ./app/CYAlert.rb

class CYAlert
  def self.show
    alert = UIAlertView.alloc.init
    alert.title = "This is Ruby"
    alert.message = "Mixing and matching!"
    alert.addButtonWithTitle "OK"
    alert.show
  end
end

If we run rake static, this will compile our project into a static library at ./build/<app name>-universal.a. We then add this to our Xcode project with the following steps:

Add static library to project
Link against additional required libraries
Initalize the RubyMotion runtime

// main.m

int main(int argc, char *argv[])
{
  @autoreleasepool {
      void RubyMotionInit(int, char **);
      RubyMotionInit(argc, argv);
      ...
  }
}

Now we're cooking with gas. One caveat: RubyMotion does not generate .h files for us, so we have to manually declare our classes and methods somewhere in Objective-C. It's a good idea to create a header for each class, so we could create a CYAlert.h like this:

// CYAlert.h

@interface CYAlert : NSObject
+ (void)show;
@end

@implementation CYAlert
// Empty on purpose
@end

And in any of our classes, such as the app delegate, we need only import the header and use to our heart's content:

// ExampleDelegate.m

#import "CYAlert.h"

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    ...

    [CYAlert show];
    return YES;
}

So if something is painful to write in Objective-C, just write it in Ruby and easily add it to your project. Super neat stuff.

You can find the source for the above examples on Github.

That Makes Us Look Really Bad.

2012-08-08T00:00:00-07:00

“That makes us look really bad.”

Square's office is enveloped by wall-mounted monitors. I'm sure they usually display some interesting charts, but they're automatically blacked-out the moment a guest like me arrives. In typical Square fashion, they're not merely turned off: they display an elegant black Square logo on a dark textured background.

However, there was one near the entrance still displaying Twitter's Feed widget with tweets about @Square. Stretched across the screen, ceaseless praise about their products scrolled by in an interface not too dissimilar to this:

I was speaking to some folks nearby, when someone looked up to the monitor and rendered that squinting expression when you first notice a scratch on your car. He uttered: “Wow, that makes us look really bad.”

Everyone turned to the newfound blemish. He continued: “I'm going to fix that later tonight. Slap on Helvetica, increase the line height, maybe add some texture.” The others concurred with his assessment.

I agreed it did need some work, but I was still focused on the first thing he said: “That makes us look really bad”. He didn't have any relation to the team who put that on the screen, but he knew the style clashed with Square's crafted image of polish and perfection. He had nothing to gain from restyling the view, but still wanted go out of his way for the good of the company. Very few would ever see that monitor, and yet its imperfection put a dent in everything that Square had achieved.

Maybe I'm making a big deal out of nothing, maybe that was just his thing. But from what I've seen from Square's employees and its products, I think it runs deeper than that. It's the kind of culture that makes amazing things happen.

Square recently made two announcements: a partnership with Starbucks and a flat monthly fee for credit card charges.

The Problem With Kickstarter And Software

2012-08-05T00:00:00-07:00

The Problem With Kickstarter And Software

David: Hey Socrates, thanks for taking the time to grab coffee with me. We're really excited about how our new software product is going to make customers' lives a lot better.

Socrates: That sounds great, how far along are you?

David: We've been hard working for the past three months and have a polished beta, but we're not quite ready yet.

Socrates: Sounds like you should start drumming up interest for a launch. What's your customer acquisition strategy?

David: Well, we're going to launch on Kickstarter.

Socrates: Oh? The crowd-funding website?

David: Yeah, we think it'll be a great platform to get some early adopters.

Socrates: But haven't you already raised venture capital? Why do you need the additional Kickstarter funds to continue work?

David: It's not about the money, we obviously don't need any more. But we do need paying customers, and Kickstarter can give us those in spades. It's less competitive than the App Store, and definitely less crowded than the entire web, so it should get a lot of fresh eyeballs on the product. It was impossible not to hear about the success of the OUYA and Double Fine.

Socrates: I see. Kickstarter unquestionably brought those projects to prominence, but are there examples of it working for unknown software-based products? OUYA is a hardware venture and Double Fine had Tim Schafer behind it.

David: Sure, Code School just met their fundraising objectives.

Socrates: But they had a tangible need for their fundraising. Mac Minis are expensive, and they made it very clear through how they would spend the funds to make the product possible. Essentially what you're planning is to take pre-orders.

David: Well, basically. We have some more perks at various levels, but yeah it's pre-ordering. It's a much more visible place for our product to be than a temporal post on Hacker News or a few blogs.

Socrates: But it's also a much more visible place for your product to fizzle. Check Pixate or App.net, which are well below their fundraising goals. They might have proven some tangible demand, but at what cost? By setting a "goal" you are also setting yourself up for possible failure. You may get a solid data-point in proving product-market fit, but it could also hurt your brand or future fundraising ambitions. What happens if you don't meet your goal? You've done months of work, will you just pack it up? Because then you get none of the money and zero paying customers.

David: We're going to pick a less ambitious goal than those projects.

Socrates: Well then what's the point of going on Kickstarter at all? It sounds like you're betting on a triumphant surge that makes you look like the Next Great Kickstarter Success. But in reality, most people just don't get excited by software like they do with a new game console or 3D goggles.

The customers who are excited about your product should find and buy your software regardless of the Kickstarter. The overlap between "people who go on Kickstarter" and "people who need your software" is probably very small, and you'll find more success specifically targeting the latter group.

There are less visible ways to prove your product is something people need. Talk to customers, run AdWords tests, get email signups, you know the drill. You have a working prototype: get it in users' hands. If it turns out you need to go back to the drawing board, then you can do so in private without losing face.

Kickstarter isn't a way out of hard work. If you know your customers, you should know how to directly market your product to them. Maybe you really do need crowd-funding for something, but make it clear what the money is going towards and why this product won't exist without it. Don't shoot yourself in the foot with a failed Kickstarter.

The Shape Of Mobile Development To Come

2012-07-29T00:00:00-07:00

The Shape Of Mobile Development To Come

Mobile is still the exciting Wild West of today's software. There's only been about five years of modern development (not going to count the Java ME dark ages) and its best practices are still being discovered.

I have some "long bets" about mobile development, which will hopefully come to fruition in the next two years. These are how I see (or would like to see) developer tools and processes evolve; maybe I'm totally wrong, but I'd love to hear what you think.

Tools Empowering Designers

Beautiful apps are hard to make. Designers are creating increasingly intricate and pixel-precise UIs, but porting these to actual code is a slow and painstaking process which usually leads to details getting lost in translation. The visuals alone are brilliant, but unfortunately what really matters is how they end up in a working product. For every rock-solid Path there are dozens of apps that have visible errors and discrepancies between what the design team intended and what engineering shipped.

When I talk to mobile-centric startups, I always ask about the workflow between design and implementation. Several companies are trying to enforce rigorous oversight to make sure everything looks and feels correct, and that is definitely one solution to the problem. But the truly frictionless way is to create new tools that empower designers and take engineers out of the equation.

Within the past few months, I feel there's been a collective epiphany about this. PaintCode and Pixate are currently addressing aspects the problem, and I know of several unlaunched efforts in the pipeline. MarkupWand and CSS Hat are really great ways this pain is being attacked on the web, and it would be interesting to see similar "PSD → Code" work done for mobile.

Chopping assets, correcting alignments, and tweaking animations aren't the core-competencies of a mobile engineer. Those tasks require many re-compilations and a continuous back-and-forth, taking up man-hours which could be put towards making the product stable and performant. Why should we keep producing our designs "twice" when converting the original might be within our grasp?

More Languages

"More languages" is generally true for all fields, but it especially proved true for the web. Writing backends gradually shifted from bare-metal compiled to higher-level scripting languages, and I think that trend will continue on mobile.

For most of the past five years, there have basically been two choices: Java and Objective-C. Objective-C in particular has evolved over the past two years to become an "easier" language with the addition of ARC and improved literals, but given the choice I would still prefer something like Ruby for most work.

Ruby turned out to be a winner on the web, so it's not unreasonable to think it might happen again on our smartphones. I've written in the past about RubyMotion, and there's also an Android counterpart Ruboto. But there still more alternatives: Nu and Clojure for Android allow you to write apps in Lisp, and Scala was used in production at Bump.

Will developers stop writing apps in Objective-C and Java? Of course not; companies still write web code in C++ and Java. However, a greater variety of languages will undoubtedly help bridge mobile development to all sorts of new developers. That's what gets me excited.

Better `CRUD` Frameworks

When it comes down to it, there shouldn't be a whole lot of business logic in most mobile software. All the heavy lifting should be done by servers, and apps act as (very pretty) shells for that data. They should cache and gracefully degrade the experience during offline periods, but internal structure should always mirror and sync with what the server dictates.

If that's true, why aren't there frameworks which make dealing with APIs as seamless as Rails makes interacting with a database? AFIncrementalStore and RESTKit are definitely steps in that direction, but they focus only on the API-Model relationship. Rails has the wonderful ability to generate views and forms based on models, so why don't we do that too?

Code speaks louder than words, so here are some ideas I've been playing around with (in Objective-C, but equally applicable to Java):

@interface User : MagicalFrameworkModel { }

...

[User find:@"1" success:^(User *user) {
    // User w/ ID 1, retrieved via API
    self.user = user;
} failure:^(NSError *error) { }];

...

// Generates a UIViewController populated with correct
// KVO for that class.
FormController *editUser = [FormBuilder controllerFor:[User class]];
[editUser setUser:self.user];
[self.navigationController pushViewController:editUser animated: YES];

...

// Creates a UI element KVO-bound to property of a model
FormTextField *observing = [FormBuilder textFieldFor:user property:@"name"];

I built some of that functionality into RemoteModel, but there's a ton more to be done in the space. If we can make CRUD development on mobile that painless, we could iterate our mobile products much faster and with less underlying knowledge of how each platform works.

Web Apps?

I think there's far more low-hanging fruit in making native development easier than in making web/hybrid apps feel "right". I've seen two just good hybrid implementations (Quora and Pocket), and yet I still run into defects using both.

The fact of the matter is there are hard technical limits to how far we can push web apps. Web views on all platforms generally eat memory and that, coupled with the lack of Nitro on iOS, means you have to put a lot of work into making them fast and stable.

I think the "write-once-run-everywhere" benefit of web views is disingenuous; the phrase should really go "write-once-optimize-everywhere". There are specific nativization techniques that work better on each platform, plus some elements like text inputs won't ever feel "right" when done using HTML and should be coded by hand. Heck, Apple's App Store app feels terrible and they make the operating system!

In the end, I don't see web views getting very much closer to native apps than they are today. Facebook, the famous proponent of the whole web-native-hybrid idea, is reportedly shifting back to native. The whole reason most companies use web views is (rightfully) writing two sets of app code is resource intensive. But what if there was another way...

True Write-Once-Run-Everywhere

This is the big bet, and the one I'm most likely to be wrong about. But if you take all of the above bets (more languages, abstractions for API communication, decoupling design from code) you can arrive at an interesting conclusion...

What if you could write true native apps for both iOS and Android with one codebase? All you need is a language that works on both platforms, like Ruby, and a level of abstraction above both MVC frameworks. The models would be easily portable, controllers on both platforms share a similar lifecycle, and with Auto-Layout coming to iOS perhaps there's an easier way to map between iOS and Android views than we previously thought.

Imagine writing code like this and having it build to native apps on both platforms:

class ListController < Magic::MetaController
  def setup_view(view)
    @list_view = ListView.new
    @list_view.fit_to view
  end

  def view_ready
    @row_data = ["Hello", "These", "Are", "Rows"]
    @list_view.rows = @row_data

    @list_view.on_tap do |row_index|
      App.alert(title: "Tapped!", message: @row_data[row_index])
    end
  end
end

The "make a language that works on both platforms" is pretty hand-wavey, but if that can exist then I think we can do really incredible things.

I'd love to hear your feedback about these wild ideas on Twitter and Hacker News!

The RubyMotion Way

2012-07-08T00:00:00-07:00

The RubyMotion Way

I love RubyMotion. And the way things are looking now, I'll never have to write Apple-platform software entirely in Objective-C again.

Don't get me wrong, I think Objective-C is a great language. I've enjoyed using it nearly every day for the past four years and it's getting better all the time.

But I find working in Ruby to be just plain fun. If you've tried projects in Ruby and just didn't like it, RubyMotion probably won't change your mind. But if you've ever wanted to make iOS or Mac apps but didn't want to get over the hump that is Objective-C, maybe this will get you going.

Rubyfication

I've done some work on BubbleWrap, which is the largest and most widely used RubyMotion gem. It aims to take all of the existing Cocoa frameworks and make them more pleasant in Ruby.

The low-hanging fruit for this effort is taking the callback-centric Cocoa APIs, which are mostly handled in Objective-C using delegates or targets, and transitioning them to Ruby blocks. Here's a quick comparison of handling button callbacks in Objective-C:

[button addTarget:self action:@selector(buttonTapped:) forControlEvents: UIControlEventTouchUpInside];

//  Elsewhere

- (void)buttonTapped:(id)sender {
    self.view.backgroundColor = [UIColor redColor];
}

and RubyMotion:

button.when(UIControlEventTouchUpInside) do
  self.view.backgroundColor = UIColor.redColor
end

Pretty nice right? BubbleWrap and other efforts are systematically going through the Cocoa APIs and making things lessLike:objectiveC: and more like_ruby.

Some magical things are happening in the process:

Nitron makes CoreData more like ActiveRecord
Teacup adds stylesheets to UIViews
My own project Formotion lets you build interactive UIs with just a hash.

Rubyists get a lot of flak for the kind of DSLs and black magic method_missing tricks the above libraries use; but you know what, maybe that attitude is just what Objective-C has been missing.

Objective-Ruby

One of the criticisms of RubyMotion is that, while a solid technical achievement, it does not alleviate the pain that is the verboseFunctionNames:inObjectiveC:.

Well, that's absolutely true. In fact, RubyMotion goes out of its way to preserve Cocoa APIs exactly as intended. To keep Objective-C-style parameters, RubyMotion adds new.functions(with, this: syntax), which looks quite like [old functions:with this:syntax] (Ruby 2.0 will have the same sort of named arguments).

This is definitely a step up from other Objective-C bridges, which pollute their languages with nasty hacks. I imagine that's one reason why iOS development in other environments hasn't caught on quite like RubyMotion has.

Maybe another reason for RubyMotion's relative success is that Objective-C, [brackets] aside, is actually a lot like Ruby. Notably, they use message passing for functions, which are interceptable and hackable in both languages. Objective-C has moved towards Ruby in recent years with blocks, literals (@[], @{}), and indexes on normal objects (like someNSObject[2]).

So actually, that UIButton example from earlier? You can now write a wrapper in Objective-C that looks remarkably Ruby-like:

[button when:UIControlEventTouchUpInside do:^{
    self.view.backgroundColor = [UIColor redColor];
}];

But that's not "the way" for most Objective-C developers, so there's no similar movement towards adopting these nice wrappers.

So I guess it turns out Objective-C is a language that's nearly statically translatable to Ruby, so long as you don't use lots of custom C in your iOS or Mac apps. And even if you do use some plain-old C, most of Apple's C APIs and libraries actually work as expected in RubyMotion!

Performance

That all seems great, but do the niceties of Ruby come at a cost?

Some are inherently skeptic of RubyMotion's performance. That's pretty reasonable, since normal Ruby has pretty dodgy performance. But there's a giant difference between Ruby and RubyMotion: compilation.

RubyMotion code is compiled to machine code and uses the Objective-C runtime. There's no interpreter, no garbage collector, nothing except bare-metal machine code that looks basically identical to normal Objective-C. MacRuby does use the Objective-C 2.0 GC, but RubyMotion uses an ARC-like system for memory management like every other modern iOS app.

1.x

All that said, RubyMotion is still 1.x software. There are bugs in some under-used APIs, occasional memory management hiccups, and some tool flakiness.

But damn does HipByte patch things quickly. Every time I've reported some weird behavior to @RubyMotion, it's fixed within a week. And they aren't just pushing bug fixes: the team continues to push awesome new features like better functional tests and static library compilation on a weekly basis. And if you want to contribute, part of the source is open to pull requests.

Unlike MacRuby, RubyMotion isn't an internal project that Apple manages according to its resources. RubyMotion is an independent, commercial product with a passionate and amazingly talented team. They have a vested interest in continuing to make it better, and I'm incredibly excited to see where it goes from here.

Why not?

With all that RubyMotion can do, why aren't you moving to use Ruby for your Apple apps right this minute?

I asked a friend a similar question the other day. He said learning iOS with RubyMotion would be like "starting front-end dev with jQuery". At the moment, there's a lot of truth in that statement. Knowing Ruby will only get you so far, as the Cocoa APIs which will make up 80% of your project are preserved in all their Objective-C glory.

But that's changing. The Rubyfication of Cocoa is going strong and some, myself included, are betting their money that it's the way of the future. And in that future, all you need to make an app is idiomatic Ruby.

So what are you waiting for? Get to it.

Blueprint for Building Native Apps

2012-06-28T00:00:00-07:00

Blueprint for Building Native Apps

How should companies build native mobile apps? I've thought a lot about this very question. It's a very different problem than web development, where you can push code 24/7 and bugs are cheap to fix. On mobile, you've got one shot to get it right and make a great first impression.

(I'd probably augment this advice for larger teams, so apply this only to smaller startups)

The first step is, as a team, step-through all the screens in your app. Start with the question, "What is the very first thing the user sees when they download the app?", and then explore what happens when they tap each button or perform all of the possible actions. Repeat exhaustively for each screen and be thorough. This needn't be a 100% final UI mockup, just a bunch of boxes with arrows between them. This should give enough information for the engineers to start building a working "skeleton" of the app.

Then fill in the screens with basic UI elements. Where are all the buttons, text-boxes, or switches on each of them? Engineering can start coding with the normal looking UI elements which ship with the operating system.

After you figure out the screens, list every piece of information you need on each of those screens. Have a screen that lists books? What about them, their title, author, ISBN? Have a screen that shows details about a book? Do you show comments, reviews, ratings, or what? Even list what instructional or marketing copy is needed for different screens. Engineers can fill in those bare screens with working (but unstyled) data.

While the engineers are filling in the bare-bones app with data and normal UI elements, your designers should start finalizing UI designs. It's basically taking your skeletons and doing this:

This is where the designers and engineers really need to collaborate. Your designer should supply specially formatted images for customizing buttons, navigation bars, tab bars, and other stock controls. The engineers should read up on Apple and Google's docs on what the dimensions these need to be, but they should never have to open Photoshop and do it themselves. (I can tell you from personal experience, a coder playing with someone else's design will probably screw it up anyway ;) ).

Both iOS and Android support types of "stretchable" images (specified in code on iOS, as 9-patch PNGs on Android), which coders should familiarize your designer with. Also make sure all of the elements come prepared for multiple densities (so @2x on iOS, l/m/h/xh-DPI on Android).

On mobile, it's incredibly important to not only consider how something looks in a static photoshop file, but also how it looks in motion. Do elements animate? How should those animations behave, can they be prototyped by the designer to show to engineers? What do different buttons look like when they're tapped or disabled? What do you show while images or data is loading from the server?

My theory is that by the time UI styling and animations hit engineering, the design shouldn't be changing much before launch. If you're unsure about a design, try to prototype and get it in your hands somehow (Keynote, quick web demo, anything) before you resort to just trying it out using real Android or iOS code. In a perfect world, the designer would drop all of the specially sized UI elements in a Dropbox folder and the developers would be good-to-go.

By the same token, designers should keep tabs on how well engineering is implementing their work. Blurry graphics? Mis-aligned elements? Wrong fonts? These should all be called to attention and fixed.

If you can't tell by the body of this message, but in my experience that step takes 70-80% of the time. A good engineer can whip up a working prototype pretty quick, but sweating the details and getting the UI right takes a lot of time. If anyone has found a better way for a custom-looking app, I'd love to hear about it!

The last thing you need to do is test, test, test. I'd try to get it in the hands of a small beta group (~30 people) and have them do regular, real-world use. Testing yourself will dead-end eventually and it's always great to have fresh eyes. Products like TestFlight are great for organizing those. And if you're launching on Android...get as many devices as you can.

And one more thing! After you launch, make sure you're collecting data about app crashes and malfunctions. Apple and Google do supply you with some crash statistics, but it's always an under-representation of the truth. You can use services like Crashlytics, or you can roll your own with some easily available libraries. There's nothing worse than your Twitter feed blowing up with customers saying, "App's crashing at " and you don't have the data to reproduce it.

Good luck!

This was originally an answer to a Quora question

Formotion - Insanely Great Forms on iOS

2012-06-24T00:00:00-07:00

Formotion: Better Forms on iOS

On mobile, we like to collect data. But we also like our apps to feel native, which creates a bit of a problem on iOS.

See, the default Phone and Settings apps use grouped-style UITableViews to retreive and present data. Coding these, especially with many different row variations, is a pain.

So I wrote Formotion, a RubyMotion library. With it, you can make this:

using just this:

@form = Formotion::Form.new({
  sections: [{
    title: "Register",
    rows: [{
      title: "Email",
      key: :email,
      placeholder: "me@mail.com",
      type: :email,
      auto_correction: :no,
      auto_capitalization: :none
    }, {
      title: "Password",
      key: :password,
      placeholder: "required",
      type: :string,
      secure: true
    }, {
      title: "Password",
      subtitle: "Confirmation"
      key: :confirm,
      placeholder: "required",
      type: :string,
      secure: true
    }, {
      title: "Remember?",
      key: :remember,
      type: :switch,
    }]
  }, {
    title: "Account Type",
    key: :account_type,
    select_one: true,
    rows: [{
      title: "Free",
      key: :free,
      type: :check,
    }, {
      title: "Basic",
      value: true,
      key: :basic,
      type: :check,
    }, {
      title: "Pro",
      key: :pro,
      type: :check,
    }]
  }, {
    rows: [{
      title: "Sign Up",
      type: :submit,
    }]
  }]
})

@form_controller = FormController.alloc.initWithForm(@form)
@window.rootViewController = @form_controller

And after the user enters some data, do this:

@form.render
=> {:email=>"me@email.com", :password=>"password", 
    :confirm=>"password", :remember=>true, :account_type=>:pro}

I think that's pretty sweet.

Check it out on Github!

Looking to iOS6

2012-06-22T00:00:00-07:00

Looking to iOS6

I was asked to go over my most anticipated features in iOS6, so here goes:

Auto-Layout

Already been said but Apple is doubling down on this and wants developers to take it seriously. At it's simplest, instead of putting a button at (x: 138, y: 406), you describe it as being in the horizontal middle and 10 points from the bottom of it's parent view. For the past five years, doing it the old way has worked fine because iPhones were always 320x480 and iPads were always 1024x768. But if Apple released a device or platform with new or variable dimensions, then these methods would break down (Apple has one such platform and already implemented Auto-Layout on it: OS X Lion).

I wrote a long time ago in What separates the iOS SDK from the Android SDK? that a big differentiator between iOS and Android is how UIs are coded. Although Apple hasn't gone so far as to add an XML structure for interfaces, Auto-Layout does bring the two platforms (a tiny bit) closer in mindset. It invalidates a lot of old tutorials and books and will take some getting used to, but it really is for the better.

Maybe Apple won't release a different form factor or platform in the near-future, but it would be naive to think that we'll forever and always deal with the above two resolutions (or retina scales of them). Auto-Layout the future, and you should code to support it.

Passbook/Pass Kit

I really like this one, but it's definitely a more complex architecture for developers. If you're making an app or website which interacts with real-world goods or experiences, you can store items relating to it in the user's Passbook. Apple gives examples like boarding passes, coupons, tickets, and membership cards.

To implement it, you generate a bunch of information on your server about the pass (all the text, styles, identifiers, etc...there's just a load of options you can use). iOS6 will install this pass data through your app, an email, or a web link. You can use your app to edit existing passes, but they must be constructed on the server. There's also a lot of work to be done in keeping passes in-sync between client and server (did the user change their seats? upgrade their membership? stuff like that). Good opportunity for a Ruby library to help out with this stuff.

As a user, this is what I'm the most excited about. There are multiple startups already trying to solve the same problem, but Apple has the sheer size and pull to make it go mainstream. Color me excited.

Privacy

After the giant contacts-privacy debacle, Apple has added privacy dialogs for most pieces of user data (location, contacts, calendars, reminders, photos). Backwards compatibility exists if permission is denied by returning no data in pre-iOS6 apps, but new apps will need to monitor for changes in permission to refresh their data (i.e. I change my mind about denying your app my contact data, so I allow it in Settings.app).

Identifiers

Apple made a big hubbub when they deprecated UIDevice#uniqueIdentifier. In iOS6, there is a distinction between identifiers for advertisers and identifiers for vendors (i.e. your ID on all the apps that Facebook makes). Use the global advertiser ID only when necessary.

This was originally an answer to a Quora question

☆ The First Summer

2012-06-22T00:00:00-07:00

☆ The First Summer

What I did one summer three years ago has shaped my life ever since.

I was 17 and armed with my first-generation iPhone. I had been trying to get into iPhone development ever since the SDK came out about a year prior but hadn't really got anywhere due to school. Summer came and I took it as an opportunity to buckle down and get something on the App Store.

I got about halfway through Beginning iPhone Development and decided I was capable of a basic table-based app. Naturally, what came to mind was a database of....brocabulary. Some friends and I were going through a period of dropping these whenever possible and it was getting awfully hard to remember all of our permutations. What else is a hacker to do but solve their own problems?

Spent about two weeks coding up the app and brainstorming with my friends for the ~100 initial terms. Submitted to the App Store around the middle of June (right around the time OS 3.0 was released) and was released a week later under the title Brocabulary. Got some downloads, made a bit of money ($0.99 per purchase), and was instantly hooked on making apps.

I mean really, how awesome was it that I could make something in my bedroom that a) made money and b) complete strangers told me they enjoyed?

So that was my first few weeks of summer. For my next project I decided that I wanted to do a game, albeit something simple enough that I could actually ship. Most iPhone games used the accelerometer for their functionality, but I wanted something more unique. I looked at all the features of the iPhone and decided the microphone was underrepresented on the App Store. I came up with the idea of blowing into it to push a paper plane.

The crucial part was figuring out how to measure the input of the microphone, which I adapted from some code I found on StackOverflow. I utilized the relatively nascent Cocos2D2 game engine to make life easier. At the time I didn't know any backend technologies, so I went with the now-defunct scoreboard hosting service CocosLive to store how long players "blew" for. After about another two weeks of work, Paper Planes was ready.

It went live on the App Store in mid-July and got something like 1,000 downloads on the first day. That was HUGE to me, since Brocabulary had only gotten ~200 downloads in its entire (young) life. Immediately I sent in an update which placed an ad on the scoreboard screen, in hopes of getting some small revenue ;) (in the end I wound up with a couple hundred dollars). Since then, it's gone on to get about a million downloads during it's lifetime.

I worked on some other apps over the remainder of the summer but I feel like this covers the important parts.

....

I went from merely taking computer science classes in school to making products that shipped to thousands of people, all in a matter of months. From then on I knew there was nothing quite like software for me. In retrospect the code was rough and the apps were a little buggy, but a kid has to start somewhere right?

I wrote about my experience making apps in all my college essays, and I think it played a big part in my admission to UC Berkeley. I got out to California and dove into the hacker scene, using my iOS skills as an inroad. One thing led to another and suddenly I'm cofounder of a Y-Combinator startup, making an iPad app. I've gone on to help build beautiful iOS and Android apps (Circle), and am now a Thiel Fellow working on app-related tools.

Without that one summer learning iOS development, none of that would've happened.

This was originally an answer to a Quora question

Android Best Practices and Tips

2012-06-22T00:00:00-07:00

Android Best Practices and Tips

I may have cut my teeth on iOS, but I have a soft spot for Android.

On one hand, it's much easier to create fluid, scalable layouts using their XML system. And thankfully, independent Activities make it difficult to write the spaghetti code you might find in poorer iOS apps (self.navigationController.viewControllers[2] anyone?).

But then again, it's Java (ProblemFactory anyone?), and Google keeps changing their minds about what good apps should look like (see: 4.0 being a total rewrite of their interface guidelines).

I've worked on some really beautiful Android apps (Circle), so I thought I'd share some knowledge I've picked up along the way:

Use RoboGuice, Google's port of Guice to Android. Takes out a LOT of glue code with both plain-Java dependency injection and really awesome view injections (see this).
Learn the Activity lifecycle. Remember to zero any dangling references at the correct times so leaks don't occur (so your on[Create/Start/Resume] should basically mirror your on[Destroy/Stop/Pause]).
Speaking of Activities, be wary of controllers/activities getting thick. On mobile there's a temptation to do a lot of animation or layout logic in the controllers. Create tertiary objects ("presenters") which handle animations + UI-only logic, which the activities call when necessary.
Design your views so they flow and expand to multiple sizes/orientations. Don't make them absolutely positioned or sized, so use dips for your measurements and align views relatively.
Learn and use Fragments now. They're relatively new in Android-land, available on phones only since 4.0, but Google is deprecating many older APIs in favor of new Fragment-based ones. They're sort of like embeddable Activities, which means you can take one Fragment you used as an entire Activity on a phone and use it as a component of a larger interface on a tablet. Kind of neat, right?
In general, practice good MVC. Activities should just take data from the models and insert them into the views, or take events from a view and tell the data to do something. Don't run URL requests or other raw data fetches in controllers.
Learn the Activity lifecycle. Intentional repetition.

Do those and you're on your way to having a solid Android app.

This was originally an answer to a Quora question

Container and Child UIViewControllers

2012-06-21T00:00:00-07:00

Container and Child UIViewControllers

Historically, iOS developers have been limited to just two batteries-included ways of organizing their apps: UINavigationControllers and UITabBarControllers. These are UIViewControllers, but are unique in that they organize other UIViewControllers as part of their content. Prior to iOS5, there was no formal way of doing the same in a custom manner; you could either manage your own view controller relationships or use one mega-controller with a complex view hierarchy. But what about today, after iOS5?

Now we have a concise set of functions in UIViewController to add or remove "child" view controllers to a "parent" view controller.

Let's say we want to implement a vertical UINavigationController, where pushing a new view controller is transitioned by a vertical slide (instead of the horizontal default).

First we define a UIViewController subclass as the container controller; lets call it VerticalNavigationController.

class VerticalNavigationController < UIViewController
  def loadView
    self.view = UIView.alloc.initWithFrame(UIScreen.mainScreen.applicationFrame)
  end
end

Pretty straightfoward: we created a view sized to fits the screen. You can add whatever "chrome" (navigation bar, tabs, etc) at this point.

Time to start working on how to get our "children" controllers in there. We need an exposed API to do this, so let's do something similar to how UINavigationController works. It's usually nice to design systems by writing public methods like these before then writing the internal components:

class VerticalNavigationController < UIViewController
  # ...
  def push(to_vc, animated = false)
  end

  def pop(animated = false)
  end
  # ...
end

We know that these two methods should:

Add/remove the view controller to some kind of internal stack.
Add/remove the view controller as a child VC via UIKit's methods.
Add/remove the view controller's view to our container's view hierarchy.
Animate the addition/removal of the view controller's view, if applicable.

Let's hammer those out, shall we?

First, the stack. Ruby has some nice methods for treating Arrays as stacks, so we'll just build ontop of those, using our container's #push/#pop as a thin proxy for the real stack.

class VerticalNavigationController < UIViewController
  # ...

  def stack
    @stack ||= []
  end

  def push(to_vc, animated = false)
    from_vc = self.stack[-1] # could be nil
    self.stack.push(to_vc)
  end

  def pop(animated = false)
    # If we have 0 or 1 view controllers, don't pop.
    return if self.stack.count <= 1

    from_vc = self.stack.pop
    to_vc = self.stack[-1]
  end
  # ...
end

We do some nice checks in #pop to make sure we don't pop to an empty stack. I established some semantics to make our lives easier: the controller we're going to display will be to_vc, and the one we're hiding is from_vc, regardless whether we're pushing or popping.

Next on our list, we need to add the UIViewController methods for adding child controllers (say that five times fast). They are:

Adding Children

to_vc.willMoveToParentViewController(container)
container.addChildViewController(to_vc)
to_vc.didMoveToParentViewController(container)

Removing children

from_vc.willMoveToParentViewController(nil)
from_vc.removeFromParentViewController
from_vc.didMoveToParentViewController(nil)

Both

container.transitionFromViewController(from_vc,
              toViewController:to_vc,
              duration:0.3,
              options:UIViewAnimationOptionTransitionNone,
              animations:lambda {},
              completion:lambda {|finished|})

In practice, addChildViewController calls willMoveToParentViewController(container) and removeFromParentViewController calls didMoveToParentViewController(nil), so you only need to use four of those in your implementation (this doesn't happen if you override automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers, but let's ignore that for now).

transitionFromViewController will handle adding/removing subviews from container's vier, so that's even less code you need to worry about.

Armed with this new knowledge, let's flesh out our implementation a bit more.

class VerticalNavigationController < UIViewController
  # ...
  def push(to_vc, animated = false)
    from_vc = self.stack[-1] # could be nil
    self.stack.push(to_vc)

    self.addChildViewController(to_vc)

    to_vc.view.setFrame(self.view.bounds)

    # transitionFromViewController: breaks if from_vc.nil?
    # so need to handle it as a special case.
    if from_vc.nil?
      to_vc.viewWillAppear(false)
      self.view.addSubview(to_vc.view)
      to_vc.viewDidAppear(false)

      to_vc.didMoveToParentViewController(self)
    else
      to_vc.viewWillAppear(animated)

      self.transitionFromViewController(from_vc, 
          toViewController:to_vc,
                  duration:animated ? 0.3 : 0,
                   options:UIViewAnimationOptionTransitionNone,
                animations: lambda {
                              # do some animations
                           },
                completion:lambda {|finished|
                    to_vc.viewDidAppear(animated)

                    to_vc.didMoveToParentViewController(self)
                  })
    end
  end

  def pop(animated = false)
    return if self.stack.count < 2

    from_vc = self.stack.pop
    to_vc = self.stack[-1]

    from_vc.willMoveToParentViewController(nil)
    from_vc.viewWillDisappear(animated)

    self.transitionFromViewController(from_vc, 
              toViewController:to_vc,
                      duration:animated ? 0.3 : 0,
                       options:UIViewAnimationOptionTransitionNone,
                    animations:lambda {
                                  # do some animations
                               },
                    completion:lambda {|finished|
                        from_vc.removeFromParentViewController
                        from_vc.viewDidDisappear(animated)
                      })
  end
  # ...
end

It seems like a lot of code, but only because the transitionFromViewControllers are broken into multiple lines. Let's walk through it.

In each function we find what controller we're going to and what controller we're coming from. Then we call willMoveToParentViewController on them (we don't do so in #push because addChildViewController handles that).

Next we handle what happens to their views. Remember to call the view[Will/Did]Appear and view[Will/Did]Disappear at the appropriate times (before/after adding/removing it as a subview). We call all the didX methods when we're done with our animations in transitionFromViewController. The only code that does anything differently is #push, which will force a manual addition of the new controller's view because there is no from_vc sometimes.

And that's about all you need! Just plug in your custom animations or chrome and you're good to go.

I've uploaded a more complete example. It's ugly, but shows how to do animations and lock a navigation bar to top of the container's view.

Clay Allsopp

RubyMotion - Year One

RubyMotion: Year One

Let Me Tell You A Story

Let Me Tell You A Story

The Purple Crayon

The Purple Crayon

Google Reader - A Product vs. A Symbol

Google Reader: A Product vs. A Symbol

Where The Puck Is Going

Where The Puck Is Going

Why There Are No Game Console App Stores

Why There Are No Game Console App Stores

How A Pull Request Rocked My World

How A Pull Request Rocked My World

Growing Old on Facebook

Growing Old on Facebook

Web Views Are Green Screen

Web Views Are Green Screen

We're Better At Design, And That's Not Good

We're Better At Design, And That's Not Good

Writing a Programming Book

Writing a Programming Book

So, What Do You Do All Day?

"So, what do you do all day?"

How It Feels To Build

How It Feels To Build

Billboards Are Like Facebook

Billboards Are Like Facebook

☆ Give A Damn

☆ Give A Damn

Don't Say Startup

Don't Say Startup

RubyMotion Metaprogramming

RubyMotion Metaprogramming

send

define_method

define_singleton_method

alias_method

instance_eval

class_eval

module_eval

const_get

const_defined?

const_set

What's not supported?

What Excites Me About RubyMotion

What Excites Me About RubyMotion

It's Just X Through Y While Z

It's Just X Through Y While Z

Mixing Objective-C and Ruby

Mixing Objective-C and Ruby

Objective-C in Ruby

CocoaPods

Ruby in Objective-C

That Makes Us Look Really Bad.

“That makes us look really bad.”

The Problem With Kickstarter And Software

The Problem With Kickstarter And Software

The Shape Of Mobile Development To Come

The Shape Of Mobile Development To Come

Tools Empowering Designers

More Languages

Better CRUD Frameworks

Web Apps?

True Write-Once-Run-Everywhere

The RubyMotion Way

The RubyMotion Way

Rubyfication

Objective-Ruby

Performance

1.x

Why not?

Blueprint for Building Native Apps

Blueprint for Building Native Apps

Formotion - Insanely Great Forms on iOS

Formotion: Better Forms on iOS

Looking to iOS6

Looking to iOS6

Auto-Layout

`send`

`define_method`

`define_singleton_method`

`alias_method`

`instance_eval`

`class_eval`

`module_eval`

`const_get`

`const_defined?`

`const_set`

Better `CRUD` Frameworks