Want to stay on top? Ruby Weekly is a once-weekly e-mail newsletter covering the latest Ruby and Rails news.
     Feed Icon

Blogo – How One Team Built a Commercial Mac OS X App with Ruby

By Peter Cooper / March 9, 2009

blogoguys.jpgBlogo is a Mac / OS X blogging client developed by Brainjuice - the business name of Benjamin Jackson and Ivan Neto, Rio based Ruby developers and Web designers - and born out of their frustration with existing commercial blog editors.

Brainjuice believe Blogo is the first commercial OS X Ruby app (though the first cross-platform one goes to someone else - see the footer of this post for info!). Rather than use Objective C (which they found to be a serious time hurdle), they tried out RubyCocoa and discovered the beauties of Cocoa (other than the rather gangly method names!) in that way instead (along with MacRuby). After a lot of work and more than a few conversations with Laurent Sansonetti [of MacRuby fame], they were able to get Blogo to release.

blogoapp.png

I asked Ben some questions about the pains, pleasures, and processes behind releasing a desktop Ruby app for Mac OS X:

Ruby Inside: Blogo is an OS X only application. Was writing for OS X your initial idea or did you look at alternatives (such as JRuby and Monkeybars)?

Benjamin Jackson: Not a chance. We don't settle for non-native interfaces. We hate AIR. We use Safari. When you take the native interface away from the user, it just feels wrong. Controls don't respond the way you know they should. Tab ordering NEVER works correctly. Drag and drop becomes drag and pray.

Firefox doesn't import our bookmarklet properly. It sticks a bunch of ugly javascript in the title. Why? Because it's being dragged from a WebKit view, not a Firefox window. And I don't want to single out Mozilla. This is everywhere, and with very few exceptions it's the unavoidable result of trying to please everyone.

Coca Cola adapts their recipes for every single country in the world. If you care about a platform's users enough to dedicate time which could be spent making your product better to make a version of your software for them, it should imply that you care enough to deliver something which does more than just compile and run on their system.

What process did you go through to package Blogo for distribution? Were there any surprises or snags along the way?

Hell! I learned more about ruby's internals than I ever wanted to know. Patched Jonathan Paisley's excellent standaloneify script to work with our build environment. Compiled every single C extension for both PPC and Intel. Hacked the main ruby file to chop the load path down and avoid crashes due to conflicts with non-standard ruby installations (hello, readers). Rewrote the entire remote IO to use native Cocoa functions with asynchronous callbacks rather than running their much more convenient ruby equivalents. Swapped out all gems which dealt with remote data for Cocoa equivalents, or rolled our own. Removed all ruby threads and used NSThreads.

MacRuby will be better. *knocks on wood*

I noticed that Blogo was quite a large install (28MB download) for what it is. Do you think large file sizes will be off putting to users and that progress needs to be made in this area regarding Ruby app packaging, or is it a non-issue from your point of view?

We build for Tiger and Leopard. We will not be doing this for long. The limitations imposed by a dual build include having to embed your entire ruby distribution as well as all gems and frameworks. Growl+Installer is one of the heavier ones. GData, HMBlkAppKit, Sparkle and rb-appscript are other disk hogs.

What advice would you give for someone looking to build Mac apps in Ruby?

Study Cocoa. Read the conceptual documentation and the HIG (Human Interface Guidelines). Learn the APIs, because you're going to have to know what that slidey thing is called before you subclass it. Cocoa forces you to wrap your brain around a lot of patterns that don't get much air time in other frameworks. Delegates and bindings don't just save programmer time, they change the way you think about your code.

Use MacRuby. It's stable and Leopard-only. Forget Tiger.

Read Apple's article on building Cocoa apps with MacRuby.

Join the macruby-devel mailing list. Give the devs feedback. They're nice guys. They'll help you.

Look into Hot Cocoa. Rich Kilmer has done a great job on this, and it looks like it will be one of the nicer bits of MacRuby. Writing little domain-specific-languages like this is generally against the sayExactlyWhatYouMeanToSay: andMore: syntax of Cocoa, but at the end of the day it's Ruby, dammit. Terse and clean makes Matz smile.

What next for you and Blogo? Do you plan to develop any further desktop applications using Ruby?

We have many plans. Some of them will likely involve MacRuby to one degree or another. Not having to compile is incredibly convenient on many levels. Some may involve Rhodes. But I don't ever see us writing an application without a single line of Objective-C. And I don't want to. It's beautiful in a strange, Lisp-y way, and reads much better than Lisp IMHO. Ruby is one more tool for us to get the job done quickly.

Thanks Ben!

Note: Blogo is far from the only commercial Ruby desktop app - David Koontz, James Britt, and Logan Barnett's JotBot (an innovative time tracking app) is also a fine example as the first commercial cross-platform desktop Ruby app (built around Monkeybars). David even posted a good wrap up of how it came together recently.

Comments

  1. Rod Schmidt says:

    Packrat (www.infinitenil.com/packrat) used to use RubyCocoa as well to render Backpack pages.

  2. Matt Aimonetti says:

    Great job by the Blogo team.
    The readers might also be interested in knowing that MacRuby 0.4 got released few hours ago: http://www.macruby.org/post/macruby-04/

  3. John says:

    Its great to see commercial apps written in Ruby being commercially distributed. Great job!

    There's one thing that really haunts me tho: having the entire source code of the application visible when you "show package contents" of the bundled application. What are your thoughts about that?

  4. Matt Aimonetti says:

    @john this is something that MacRuby is planning on fixing in a future release. In the meantime, if you are really worried about a part of your app that you don't want anyone to see, you can write this exclusive part in obj-c or use a ruby to c compiler.

    - Matt

  5. John says:

    @matt True, you can interface obj-c with ruby to 'hide' the parts you don't want anyone to see, but with Blogo's example I was able to easily skip their license verification in the part where their ruby code interacts with their 'hidden' license validation obj-c controller.

    IMHO I don't think there's a very safe and secure way to prevent the above from happening until ruby gets some sort of pre-compiler/compiler.

  6. Matt Aimonetti says:

    @john true, hopefully MacRuby will support compilation in a near future. But if people really want to crack your app, they will find a way to do so.

  7. Chris says:

    This sounded great until I saw their reply to the "Were there any surprises or snags along the way?" question. I could be wrong, but that sounds like a hell of a lot of really difficult, time-consuming work. Once that is taken into account, wouldn't it have been just as fast to code the whole thing in Objective-C? Don't get me wrong, I love Ruby, but Objective-C is a very nice language once you get used to it.

  8. David Berube says:

    CastingFrontier's iSession software predates this by at least a year and a half or so.

    Take it easy,

    David Berube

  9. David Berube says:

    Actually, upon further research and realizing that this interview is *not* an initial release announcement, the numbers are a bit closer - they might be right.

    Take it easy,

    David Berube

Other Posts to Enjoy

Twitter Mentions