RubyMotion Success Story: Bandcamp
Bandcamp is an online music store, as well as a platform for artist promotion, that caters mainly to independent artists. Artists on Bandcamp have a customizable microsite with the albums they upload. All tracks can be played for free on the website and some artists offer free music downloads.
Bandcamp recently launched their new iPhone application and it has been written with RubyMotion. We sat down with Daniel Dickison to talk about his recent experience using Ruby to build an iOS app.
So Daniel, you're at Bandcamp, what's your role over there?
I am a programmer and sort of, the way we do things is all the engineers do a little bit of everything. We're not too specialized, but obviously I've been working on the mobile app, so that's been my thing for the better part of this year.
It's been a solo endeavor?
Mostly, although definitely wasn't totally solo. We have two dedicated designers on the team. So the designers did the design and I did most of the coding. Though a couple other people helped out during the process.
Tell me a little about Bandcamp, what kind of a company is it?
We do music. It's a music platform for mainly independent artists and also labels. So it's a platform for people to put their music up and distribute it and get paid directly from fans for buying music. That's sort of the main thing we do.
Is it a pretty big startup?
I don't have much of a sense of whether we're big relatively. I don't have much of a context. Let's see I think we're something about 15 employees now. We just celebrated our 5th anniversary, 5th birthday of Bandcamp was just a couple weeks ago, so we had a special blog post.
That's right! With very cool ASCII art.
Oh yeah that's Moni, our designer, he's the ASCII art master.
He does a lot of ASCII art stuff in the group IRC that we're always on.
It's one of those things you'd expect to be a lost art, and instead it proliferates.
Mmhmm. It's kinda fun, I don't know how people make those, but I'm always impressed when it's animated.
I'm wondering more about the "Bandcamp platform". Is that to say that people build applications using your platform, or is it that you can build multiple applications with?
Oh I meant platform, not in the technical sense, but as artists using the site to promote their own music. We don't set prices, artists basically control their own Bandcamp page. They can give music away for free, or for pay, name your price is like "the big thing" these days.
So the web application has been around for five years?
Yes, that's basically what it was, exclusively, until the app. And the app itself is a compliment to the site.
What led to the mobile app? What was lacking?
There's really, the one big thing was, when fans buy music on Bandcamp, before the app, you would basically get a download for the music, whether it's a track or an album. If you wanted to listen to it on your phone you would have to download it on your computer, then load it onto itunes, then sync that to your iphone, which works, but is 5 steps more than we want people to have to do just to listen to what they bought on their phone.
So the big idea is if you buy something on the site, then you should be able to seamlessly listen to it on your phone, which is the first and main problem that we wanted to solve on the app.
Gotcha, so you wanted a way to download directly to the device and play it, pretty much be one action.
What led to the decision to use RubyMotion for the iOS app?
That's an interesting story! So the site's written almost all in Ruby, on the server side, so all the engineers here know Ruby. Personally I've done some iOS development, so I would have gone with Objective-C and written it that way, but Joe, who is head of engineering, I think he was familiar with MacRuby from before, so he heard about RubyMotion and suggested it, and the big plus is that it's a lot easier for other engineers to jump on the project. It's a different API but the language is what we're all used to doing on the server side already. So really that's the big reason.
Has anyone else reviewed your iOS code?
Yeah, so actually after v1 went out, we're working on new features, we actually have another guy that's doing iOS stuff almost full time now for features, and Joe was another one who spent a good chunk of time working on the iOS app.
How was it, introducing them to the organization of the code, and where things go, what was that learning curve like for them, for the new developer?
I'd say, there's still a learning curve, because the UIKit stuff, it's a pretty big API to wrap your head around, but it definitely seems like it's a lot easier to add new features. We look through the code and the syntax is all straight up Ruby.
So the language isn't getting in the way.
Yeah, kind of an interesting aside, back when we were still prototyping the app, I had an idea to do the UI as a Web view. If that had panned out, it would've been really cool because the backend code would've been all Ruby without a lot of the UIKit layers. It would've been very straight up server type code on the backend with Ruby, and the frontend would've been HTML/Javascript. We didn't end up going that way in the end, because it worked pretty well, especially on iOS, it works really well, but it didn't work that well on Android. You lose most of the gains of doing it cross-platform anyways.
Gotcha. Let's talk more about early prototyping. Were you able to use RubyMotion to your advantage there?
I think so, a lot of simple things get really simple. I'm thinking the basic whether you're matching regular expressions with strings, or iterating your arrays or working with hashes, that stuff is so much less verbose, doing it in RubyMotion. And the other, I guess it's both a pro and con, is not having to work in Xcode. I use Sublime Text myself, but it's nice being able to drop right in to the editor you already have customized and not having to have this gigantic IDE. Although, it's not so bad and definitely getting better.
Actually for a while I was using Sublime Text and switching to Xcode to compile, I would switch back and forth. But it is a difference. For me, Xcode doesn't become part of my work flow as well. I can integrate iterm and Sublime Text, I can have them talk to each other very easily.
I feel like if you want to use Xcode to the full extent, you have to let Xcode be the world. Use storyboards, do everything in Xcode because everything's integrated well.
What kind of RubyMotion tools were helpful, like what's your workflow look like?
We didn't use a lot of CocoaPods or anything like that, this was a decision I made early on, because I'm familiar with Ruby and I'm familiar with UIKit and Foundation and all that, a lot of the nice Ruby wrappers I just wanted to write myself, just for maintainability, because you guys are iterating pretty quickly, and iOS SDK's change, not as drastically but you do kinda have to stay on your toes to keep up to date with new APIs that come out, and get deprecated. So it seemed like it might be a good idea just to do it all in our own custom code that we have a good understanding of and can easily change if we need to update it for various things.
My workflow is basically a terminal window open that's firing off rake every time I need to compile, and a Sublime Text window and Dash is awesome for documentation because when you don't have the Xcode, I dunno what you call it, the assistant window, and option-click to get documentation, it's super super useful to have Dash.
I would agree that's the thing that I would love to see implemented, is autocompletion. I guess RubyMine has a very good one but I haven't seen one for Sublime Text. I don't know how'd you do that anyway, that analysis.
Yeah, maybe this exists already but it's probably possible to just hook up a key binding to take whatever string your cursor's currently in and hand that off to Dash. Which I should probably look into, that would be pretty useful.
What I would love is if I started to type UIControl and then I could choose StateNormal, and it would flow off my fingers. Though, for that specific example I use SugarCube of course, it has helpers for that.
I noticed recently that the Sublime Text plugin for RubyMotion recently updated for Sublime Text 3, I haven't installed that yet, I should probably check that out because I think a lot of it would just be having autocompletion for a lot of the constants.
Do you use any gems or CocoaPods?
No we don't actually, we do use some third party libraries, which are pure Objective-C. FMDB is Objective-C wrapper around Sqlite, and Reachability wrapper, just real simple Objective-C stuff. We wrote some Objective-C ourselves. There's a few parts, there's an audio player, one of the main features we have, that we wanted, is to play a track we just bought, streaming, from the server, but we also wanted it to be cached for subsequent plays. It turns out you can't do that with the built-in AVPlayer API. It'll stream, but it won't give you the data to cache it at the same time. So we wrote a little audio player, using the audio queue API. So that's a C API. It may have been possible doing it in Ruby, but it was just easier just to drop into pure Objective-C and C. So we have that.
You expose that with Objective-C classes?
Yeah it's basically an Objective-C wrapper around the C API. It basically takes a file and we can play audio from a file as it's being written out from the server. So that's a low level thing we had to write in Objective-C.
Another thing that RubyMotion contributes to is the ability to organize code differently than you would in Objective-C, I wondered if you had any thoughts on that.
Yeah, actually that's kind of interesting, I hadn't thought too much about it... not having .h files for everything is quicker when you're writing code, you can just start pounding out code without having to switch back and forth, making sure your header and your exposed APIs, and worrying about that stuff. So it's definitely faster, I think.
Any other metaprogramming techniques that you rely on?
Oh yeah let's see, I think there were some. There's some utility base classes that, depending on whether TestFlight SDK is defined or not, if it isn't it'll stub it out with a dummy class that pretends like TestFlight SDK is there. There's definitely little funky Ruby meta-programming stuff that we can do that we throw in there.
Were there any issues with RubyMotion things that hung you up?
There's definitely one thing that was a huge time sink which was the memory management, especially with blocks and multi threading. I filed some bugs with you guys about this, and a lot of it got sorted out.
Any feature requests, things you'd like to see, in terms of RubyMotion?
Let's see... that's a good question I mean the profiling one would have been a huge one but you guys got it already, that would've been one. You know it's actually pretty solid. I think once you guys get this retain cycle and memory management stuff solid, I think that would make it, without question a solid platform to develop in.
Great! Any questions for our side?
I'm curious, are you guys a distributed team?
Yeah we're all over! I'm in Denver, I pretty much step in for the interviews, for community projects, kind of poke around the mailing list as much as I can. Most of the team is in Europe, though we've got Watson in Japan, in Tokyo. So he and Laurent have been the main, core developers, though Eloy Duran is also entered into that world.
We're also distributed, it's interesting to hear about other teams that do that. We do a daily Google Hangout meeting to give status, to keep up to date, I was wondering if you do stuff like that?
Nothing so formal, we are always in HipChat, and it's actually kinda fun because the sun never sets on the HipByte chat, because it transfers from Japan to America to Europe, and there's this perfect 8 hour difference between each one, it just depends on who's awake. There's always at least one person to hand it off.
I think we're pretty close to that! We have a guy in Australia who keeps the lights on when everyone else is out, and then a guy in Oxford, and the rest of us are scattered around the Americas. It's pretty good for us, too, because if there is an emergency, there's usually someone around there's usually someone around to take care of it.
We don't get to take advantage of that, there's usually not compiler emergencies, like there is on the web.
Haha emergencies accumulate a little more slowly.
A little, yeah, and you can always fall back to a previous compiler version, usually that resolves it for the short term. Well Daniel I don't have any more questions for you, I really appreciate you taking this time. And I hope you continue to make apps using RubyMotion.
Oh yeah we're in it for the long haul with this app. You'll definitely hear from us, I'm sure.
Great, congratulations again on shipping!
kianamaiart
pixelskylines
gummygunk
annaxmalina
kaledo-art