Tag Archives: mac

I didn’t go to C4

C4 was last weekend and looked like a lot of fun. Unfortunately I was about travelled-out this year with RailsConf and WWDC. Perhaps next time.

Daniel Jalkut was the first I saw with nice write-up. He provides “a speed-through of sessions”:http://www.red-sweater.com/blog/213/c4-abridged and closes with what is probably the biggest draw for attendees:

“As inspiring and as much fun as the scheduled speakers were, the unstructured social time both between sessions and in the evenings were just as much fun, and probably just as educational.”

I subscribe to a couple dozen Mac developer blogs, and keeping an eye on Flickr and Technorati tags for C4 is another great way to see what developers are up to. Mr. Rentzsch himself has a “set of links here”:http://rentzsch.com/c4/zeroLinkage, and Mike Zornek just posted some “short videos of the room”:http://clickablebliss.com/blog/2006/10/25/c4_photos_and_movies/ that give another view of the show.

When I go back through my older Mac programming posts, I’m reminded that I don’t really blog about Mac development as much as I used to. Perhaps that is because there are so many other good Mac guys blogging now.

RubyCocoa

I write Mac software, but over the last year I’ve increasingly been building Ruby on Rails web apps as well. Today I finally took a look at “RubyCocoa”:http://www.rubycocoa.com/. I wanted to whip up a quick Cocoa app that would involve some text parsing, and a dynamic scripting language like Ruby is a much better fit for text processing than C, C++, or Objective-C.

It turns out RubyCocoa works amazingly well. I have only scratched the surface with a small test app, but I was blown away by its ease-of-use, Xcode integration, example projects, and apparent maturity. You have full access to AppKit from Ruby-based controllers and views, and a single NIB file can even reference both Objective-C and Ruby classes. Fantastic stuff.

I don’t know if it’s ready for commercial software use yet. For distribution, I tested including the RubyCocoa.framework inside the application package and the app launches and runs correctly on a system without the full RubyCocoa install. There may be issues with requiring a recent version of Ruby, but otherwise it’s a fully native app.

My only disappointment was in the Objective-C calling conventions. There are two versions to choose from: a style using underscores to separate named values, and a slightly easier Ruby syntax using symbols and extra parameters. Here they are:

Objective-C:

[my_window setFrame:r display:YES animate:YES]

Ruby Underscores:

my_window.setFrame_display_animate(r, true, true)

Ruby Symbols:

my_window.setFrame(r, :display, true, :animate, true)

In my opinion, a better approach would be to take advantage of Ruby’s trick of allowing the last parameter to be a hash supplied without the curly braces. This feels more readable to me and more closely matches the Objective-C equivalent.

Better:

my_window.setFrame(r, :display => true, :animate => true)

In any case, that’s a minor complaint and doesn’t take much away from the beauty of writing native Mac apps in Ruby.

Last week, Joel wrote about

Last week, Joel wrote about Mac software developers:

“There are very few conditions under which it is actually the right business decision to develop software for the Macintosh. Developing for the Mac is not a whole lot different than creating a web site that only works on Netscape.”

Of course he gets some things wrong and misses the point on others. Luckily the comments in his discussion forum provided a good balance to his argument. Even Dave Winer jumped into the game this morning, bringing his perspective as a long-time Apple developer who embraced Windows development while Apple was suffering from vision and profitability problems in the 90s.

And then there’s Brent Simmons: “Why I develop for Mac OS X.” There’s also some good stuff in the comments below the essay. The essence of his argument is simple: Windows programming is boring.