RubyMotion is interesting, but I don’t have any plans to use it myself, especially for client work. There are two reasons.

The first is from a business standpoint. I learned long ago to put aside my own opinions of how things should be done whenever possible and to swim with the current. This applies to managing servers (use the package manager and avoid installing your own software) and developing software (understand the intention of the API’s author and use it accordingly).

Apple ships a lot of open-source software with OS X, but they aren’t great about keeping up with releases. Nor are they good at supporting alternative ways to write software on their platforms. Remember Java, RubyCocoa, and PyObjC? This is even true, to some extent, of MacRuby. Apple paid Laurent to work on MacRuby, yet MacRuby never shipped with an OS X release. If you want to use MacRuby in a shipping application, you either require your users to install it (terrible UX) or embed it yourself (at a cost of 10+ MB to your app bundle).

Lion shipped on July 20, 2011. It includes Ruby 1.8.7-p249. 1.8.7 has been in maintenance mode for a long time and Apple has ignored numerous patches.

• p299, released on June 23, 2010, over a year before Lion
• p302, released on August 16, 2010
• p330, released on December 25, 2010
• p352, released on July 2, 2011

The Ruby core team has encouraged people to move to 1.9 since the official release of 1.9.2-p0 on August 18, 2010. There are no signs that Apple will move the system Ruby to the 1.9 series in the upcoming Mountain Lion release, either, nearly two years later.

I’m offering all this as a long-winded way to say that I do not put much faith in Apple’s desire to avoid breaking a third-party toolchain such as RubyMotion when they can’t be bothered to do a good job supporting the Ruby they ship on OS X. It’s less troublesome, but still an issue, that they never shipped the MacRuby framework, which they paid an employee to work on.

If Apple were to break RubyMotion, intentionally or otherwise, in a future iOS release, I would be unable to fix those apps until RubyMotion adapted to the change, however long that took. In the meantime, the apps would be broken, making users unhappy. If the apps were for clients, my choice of a third-party toolchain will reflect very badly on me, as well.

Objective-C is how Apple wants developers to build apps for iOS. Choosing something else means swimming against the current and invites trouble later. At the very least, the pool of available talent is massively reduced. This puts my clients in a bad place if they can’t or won’t come back to me for updates.

My second concern is about programmer productivity. Xcode takes a lot of abuse, and Xcode 4 has been somewhat of a step back, but it’s still a pretty good IDE. I may in the minority, but I really like the wordiness of the Cocoa APIs and the way that Objective-C’s mixes arguments into the middle of method names. For any method that takes more than two arguments, this naming style saves me from needing to remember things. Xcode’s code completion is crucial to this, though. When it stops working, writing to the Cocoa APIs is painful.

One of RubyMotion’s selling points is that I get to use my preferred editor. Does any text editor offer intelligent code completion for classes from both frameworks and my own source files, without a manual indexing step? If not (and I doubt it, since it’s a big job), then I’m back to having to remember things, and a lot more than just the order of method arguments.

RubyMotion also throws Interface Builder out. The promise is that you’ll build interfaces in code, using an ASCII art style similar to Cocoa Autolayout. I don’t see this as anything other than an admission that RubyMotion can’t work with IB. It is a huge weakness, perhaps worse than the code completion problem.

RubyMotion is an interesting idea, but I won’t consider it for anything more than prototyping in the near term.

Update: Ian Phillips demonstrates that it is possible to use Interface Builder, but very minimally. You can lay out the interface, but that’s it. No outlets, no actions and no storyboards (which are great, if you haven’t tried them yet). A big part of what makes the Cocoa + IB combination so wonderful is that we can freeze dry a set of objects that make up an interface and later recreate them, with all their connections intact. This work must still be done in code with RubyMotion, which is ugly. Until RubyMotion can support NIBs 100%, it might be better not to use them at all.

I’m starting a new Rails project. I want to use Ruby 1.9.3 from the beginning to ease a future upgrade to Rails 4.0, which will require it. This presented a few issues I had to work through for my development and production environments.

Mac OS X ships with Ruby 1.8.7, but I’ve been using RVM to manage different Ruby versions in development and it’s worked fine. Debian is my preferred server distribution and the latest stable release includes Ruby 1.9.2-p0.

I’m not completely comfortable with using RVM in a production environment, and I don’t want to take on the work of installing my own Ruby entirely by hand, so this led me to look at rbenv, a lightweight alternative to RVM. It seems better suited for use in a production environment. I like to match development to production when possible so there are less things to remember, and so I switched to rbenv on my development machine, as well. Paired with ruby-build, it gives me the important features I used from RVM (I never made much use of gem sets).

It did not go well.

$ rbenv install 1.9.3-p0
$ RBENV_VERSION=1.9.3-p0 gem install bundler rails
$ rbenv rehash
$ RBENV_VERSION=1.9.3-p0 rails new app
...
/Volumes/User/Steve/.rbenv/versions/1.9.3-p0/lib/ruby/1.9.1/net/http.rb:799: [BUG] Segmentation fault
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.3.0]

Searching for solutions led me to suspect that this is due to a library version mismatch between the compiled Ruby and a gem. MacPorts can make this more common, because unlike Homebrew, it imposes strict control over dependencies and will install a new version of something (e.g., OpenSSL) even if Mac OS X ships with an older one that would work fine.

Rather than track down the problem library, then figure out how to ask rbenv to link with a different version of it, I decided to try Homebrew.

It worked flawlessly. The error when creating a new Rails project is gone.

What really sealed the deal for me came next. I like PostgreSQL, partly because it supports additional data types that can be very useful. One example is cube, which is used by the earthdistance extension to store locations and do fast proximity searches. On MacPorts, installing those “contrib” extensions is a manual, clunky process. On Homebrew, all the contrib extensions are already compiled and available.

Sold.

I finally realized today that this doesn’t matter. Unlike the rest of the gems your Rails application uses, Bundler lives above the fray. It is perfectly safe to use a prerelease version of Bundler on your development machine and stick to the stable release on your production servers.

I encourage you to give it a try. bundle install imposes practically no overhead over the actual gem installation time, and bundle outdated is tremendously useful when planning for gem updates.

$ gem install bundler --pre

Just because your configuration file’s contents are written in a DSL does not mean you should pretend it’s not Ruby anymore.

The worst offenders are those that name these files without a reference to the thing that uses them. Bundler‘s “Gemfile” and Foreman‘s “Procfile” are two examples.

It’s not that Objective-C doesn’t have test frameworks. There are several: OCUnit (bundled with Xcode), GHUnit, Cedar and Kiwi. Cedar and Kiwi use blocks to get close to an RSpec-like syntax, but there’s only so far it can go. Objective-C can’t match Ruby when creating a DSL, even with preprocessor abuse.

Fortunately, there is a way to write tests in Ruby and run them against Objective-C code: MacRuby. MacRuby is an implementation of Ruby 1.9 that compiles Ruby to LLVM bytecode and has full access to Objective-C frameworks. You can write full Mac desktop applications with it, but for this post I’ll simply use it to write test specs with RSpec for testing Objective-C classes.

In this post, I’ll walk you through how to install MacRuby, RSpec and how to set up your Cocoa (Mac or iOS) project to unit test with RSpec. These tests are analogous to model specs in Rails. We’ll be testing classes in isolation, not trying to recreate the Cocoa environment in order to test window or view controllers, etc.

A big caveat for iOS developers: MacRuby loads Objective-C code from a framework, but iOS targets don’t support building frameworks. What this means is that you don’t have access to the UI* classes in the code under test. This limits what you can test. Pure model classes (those without any external dependencies) will be fine. Theoretically, it should be possible to find the simulator frameworks and link against those, but I’ve been unsuccessful thus far. Chameleon might help if you want to dig into this further.

With that out of the way, let’s get started. If you haven’t already, download and install MacRuby. This places the macruby binary and other Ruby tools you’re familiar with (irb, gem, rake) in /usr/local/bin, with mac prefixes.

Then, install RSpec 2.5 (at present, there are problems running specs with 2.6).

$ sudo macgem install --bindir /usr/local/bin --format-executable rspec -v '~>2.5.0'

--bindir ensures the rspec script doesn’t overwrite one that might already exist in /usr/bin, and --format-executable adds the mac prefix to it, so it matches the other MacRuby-provided scripts.

In Xcode, open your project and create a new target (File -> New Target). Use the Cocoa Framework template, found under Mac OS X, Framework & Library. Call it whatever you like. I used “Specs”. Do not use Automatic Reference Counting. MacRuby, like MRI Ruby, is garbage collected and will use the Objective-C garbage collector. If your project uses ARC, that’s OK. retain, release and autorelease are no-ops under GC, and nothing changes if the calls to them are missing in the first place. Include Unit Tests should also be unchecked.

You must adjust some build settings for the new target. Under Apple LLVM Compiler – Language, find the settings for Objective-C Automatic Reference Counting and ensure it is set to NO. Just below that, set Objective-C Garbage Collection to Supported.

Go to the target build phases, and add the .m files you wish to test to the compile sources phase. As you add files to your project later, be sure to check the boxes for both your main target and the Specs target if you want to test the new code.

Finally, you need to configure the schemes for the new target. In the build scheme, check the run box. In the run scheme, choose /usr/local/bin/macruby as the executable to test.

Set up the arguments to pass to the executable when it runs as follows:

Choose your framework as the base for expansions. You’ll pass two arguments to the program: the path to the RSpec wrapper and the directory containing the specs.

You might wonder why we’re using MacRuby as the executable to test instead of RSpec directly. If you try to use RSpec, Xcode won’t recognize it as a 64-bit executable and will refuse to run it under the debugger. It will work, but you must also choose “debugger: none” and give up your breakpoints, etc.

With this new target you get a new top-level group in your project. Xcode has also created Specs.h and Specs.m, which we don’t need. You should delete them.

Create a new file in this group called spec_helper.rb and paste this in:

framework 'Specs'
 
# Requires supporting ruby files with custom matchers and macros, etc,
# in spec/support/ and its subdirectories.
Dir["#{ENV['SRCROOT']}/Specs/support/**/*.rb"].each {|f| require f}
 
RSpec.configure do |config|
  # == Mock Framework
  #
  # If you prefer to use mocha, flexmock or RR, uncomment the appropriate line:
  #
  # config.mock_with :mocha
  # config.mock_with :flexmock
  # config.mock_with :rr
  config.mock_with :spec
end

At this point, you should be able to choose your new target from the scheme picker in the toolbar and run. We haven’t created any specs yet, so you should see this:

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys004
[Switching to process 1636 thread 0x0]
No examples were matched. Perhaps {:if=>#<Proc:0x4007553a0 (lambda)>, :unless=>#<Proc:0x400795b60 (lambda)>} is excluding everything?

Finished in 0.0331 seconds
0 examples, 0 failures
Program ended with exit code: 0

You may not see any output. You can use ⌘7 and look at the most recent log or use this tip from Martin Pilkington to create a new window for output. I find this much less intrusive than allowing Xcode to constantly pop up the debugging panes in my editor windows.

Let’s create a simple spec file. Assuming you added a .m file that implements a class called Foo, create a new file in your Specs group called foo_spec.rb:

require "#{ENV['SRCROOT']}/Specs/spec_helper"
 
describe Foo do
  it { should be_an_instance_of(Foo) }
end

Run again and you should see this:

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys004
[Switching to process 1796 thread 0x0]
.

Finished in 0.40422 seconds
1 example, 0 failures
Program ended with exit code: 0

It works! Now try adding breakpoints, mocking and stubbing objects, etc. You have all the features of RSpec available to you.

I’ve been using Passenger Standalone instead of WEBrick or Mongrel for a while and it’s great, but Pow simplifies things even further: now I don’t even have to restart the server when switching between projects.

The only thing that bothered me is that it installs a firewall rule to forward traffic from port 80 to 20559. I do some PHP work under the Apache that ships with OS X and I don’t want to add a port number to my URL there, nor do I want to uglify those nice new .dev URLs for Pow.

Oddly enough, though, this isn’t true for me. If I go to localhost, up came the expected page from Apache, while foo.dev went to Pow. I didn’t specify a port for either.

What’s happening is that localhost is resolving to an IPv6 address (::1) and the ipfw rule doesn’t cover IPv6, only IPv4.

In this case, “it’s not a bug, it’s a feature” is 100% true. I hope Pow never “fixes” this.

Update June 29: Sadly, while I haven’t updated Pow, Mac OS X 10.6.8 now resolves “localhost” to the IPv4 address and this little trick has stopped working for me. Using the IPv6 loopback address is still OK: http://[::1]/.

dlopen(/Library/Ruby/Gems/1.8/gems/mysql2-0.2.6/lib/mysql2/mysql2.bundle, 9): Library not loaded: libmysqlclient.16.dylib
Referenced from: /Library/Ruby/Gems/1.8/gems/mysql2-0.2.6/lib/mysql2/mysql2.bundle
Reason: image not found - /Library/Ruby/Gems/1.8/gems/mysql2-0.2.6/lib/mysql2/mysql2.bundle

That example is from the mysql2 gem, but the same problem exists with the older mysql gem. The problem is that the libmysqlclient shared library in the MySQL 5.5 package does not specify a full path to the library. When something links with it, such as the MySQL gem, it won’t be able to find the library at runtime.

There are two ways to fix this.

1. The easy way: modify DYLD_LIBRARY_PATH in your .bash_profile (or equivalent if you use another shell). The advantage to this method is that it fixes it once for anything that links with the MySQL client libraries going forward. Add:

   DYLD_LIBRARY_PATH="/usr/local/mysql/lib:$DYLD_LIBRARY_PATH"

2. The hard, do-it-again-someday way: modify the .bundle files within the gem to use an absolute path to the MySQL client library. The fix is lost when reinstalling the gem or updating to a new version and must be reapplied. Change to your gem’s root, somewhere like /Library/Ruby/Gems/1.8/gems/mysql-2.8.1 or .../mysql2-0.2.6, or even both. There are two .bundle files within the gem (under lib and ext) that you must run the following command on.

   $ sudo install_name_tool -change libmysqlclient.16.dylib /usr/local/mysql/lib/libmysqlclient.16.dylib mysql_api.bundle

The second problem with the MySQL 5.5 packages is in the MySQLStartupItem and preference pane. Neither work to start or stop the server.

1. The ownership of the StartupItem files is wrong. OS X complains with

   “/Library/StartupItems/MySQLCOM” has not been started because it does not have the proper security settings.

   To fix that, run:

   $ sudo chown -R root:wheel /Library/StartupItems/MySQLCOM

2. basedir and datadir are not set in /usr/local/mysql/support-files/mysql.server, which breaks the preference pane. Edit that file with superuser privileges (sudo mate or vi, joe, …) and set them:

   basedir=/usr/local/mysql
   datadir=/usr/local/mysql/data

That isn’t true on Rails 3, though, so over the last few days I’ve taken the time to reevaluate the plug-in and figure out how to do the same work in Rails 3. The result is the new sql-logging gem. The source is hosted on GitHub and the gem itself is available, like any other, on rubygems.org.

Externally, little has changed. sudo gem install sql-logging (or put it in your Gemfile and bundle install), then restart your application., You’ll see additional information in your console: a count of rows returned by each SQL statement, a rough count of bytes in the response, a backtrace that shows you exactly what triggered the execution, and a top 10 list of the most time-consuming queries in each request.

I moved configuration out of the ActionController::Base class and into SqlLogging::Statistics, but the names are (mostly) the same. Check the README for details.

I’m not sure of the proper place to report this bug, but a quickie workaround is to uninstall the newer rspec-rails gem so that 1.3.x is the newest in gem list.

One thing that caught me up was the deployment suggestion to require 'bundler/capistrano' in deploy.rb. If you installed Rails 3.0 soon after it was released, you may still have one of the Bundler 1.0 release candidates. I had RC3, and it didn’t include the Capistrano file, which led to a load error. Update your gem, and all will be well.