Kevin Sylvestre

Lessons Apple Should Learn from Ruby and Rails

I’ve been a practicing iPhone and Mac developer for a few years now and I love many aspects of Apple’s platforms. The interface design software is incredible, programs run fast even on mobile devices, and the the code debugging tools are great.

However, with experience comes bitterness. Perhaps my undoing is that I have also been writing Ruby (on Rails) code for about the same amount of time. Rails has introduced me to a variety of conventions that I think should be in the Cocoa frameworks. So, I’ve decided to compare and contrast Cocoa and Rails and list my two biggest issues.

The first issue with Mac development is the language. Objective-C might have been the hottest thing in town in the 1980’s but it has ‘cooled off’ over the last 20 years. One of my biggest frustrations is with the amount of code required to get started. For example, compare these two class declarations:

Ruby:

Objective-C:

I feel like the above code should explain where my frustration stems from. Having lots of code is a liability. It is difficult to read, difficult to troubleshoot, and easy to do wrong. It seems impossible to practice Objective-C programming and follow the DRY (don’t repeat yourself) paradigm.

The second major problem with Apple development is that the framework designers went in with bad goals. I first learned Cocoa by watching presentations from Apple Engineers and can remember hearing “Cocoa makes the easy things easy and the hard things possible” as a mantra. As Robert Martin stated in his 2009 Rails Conference presentation in “What Killed Smalltalk Could Kill Ruby Too” this is incorrect. The real motto should be something along the lines of “make the easy things trivial and the hard things easy”.

A great example of making hard things easy can be found in how Rails handles persistent storage. Active Record was integrated into Rails to make saving, storing and updating database records a breeze. Core Data was designed by Apple to torture developers. For example, see some of the steps required to make the previous example persistent:

Rails:

Cocoa:

This isn’t a language limitation, this is a framework problem. Core Data could have been designed to give developers the same one line access to data that Rails has, but good defaults were never selected. As such flexibility was created at the cost of many developers sanity. Apple should have set out with a set of goals for doing basic CRUD operations without ever having to look through copious amounts of documentation.

Although you probably think that I hate Apple, let me assure you that the opposite is true. I understand that the hardware and software shipped by the company over the past five years will be marked as some of the best ever created by consumers. I only hope that someone in Cupertino is still thinking about the developers.

The Switch to Rails 3

Switching to Rails 3 for a recent project wasn’t an easy decision. On an initial investigation, too many GEMS lacked support for the latest offerings of the community. However, the excellent new router and ability to integrate more easily with a variety of JavaScript frameworks made switching worth the costs (thus far). If you are interested in switching, be sure to http://www.railsplugins.org/ and see if compatibility will be an issue for you. Otherwise, go for it!

Recurring Billing

Most web app ideas fall under an advertisement model or a freemium model. In the later case, a great application to simplify recurring billing is Chargify. The software lets developers link to a payment form or integrate custom forms with the service through a RESTful API (or a gem).

Once integration is done, administrators can track and update subscribers through a gorgeous web interface.

Overall, the application is easy to use and offers many features over ActiveMerchant. The support team for the application is generally quick to respond and the pricing is reasonable. Looks like a big time saver.

Must Have Services in Rails Web Design

Ruby on Rails is what it is because of all the great services that extend and augment it. Here is a quick overview of some services that make creating web apps downright cool.

Hosting

Heroku provides online “cloud” hosting for Ruby applications (Sinatra, Rails, etc.). It uses GIT to deploy and runs on Amazon EC2 servers. The service is free for small applications and reasonably priced for others. Deployment can be done in under a minute.

Databases

MongoHQ and Cloudant are “cloud” MongoDB and CouchDB data stores. According to some, these schema-less services are doing to databases what Rails did to web frameworks: revolutionizing. MongoHQ is free for 16 MB databases and Cloudant is free for 1 GB databases.

Files

Almost every application has some data that does not fit (well) into a database. Picture, video and audio files are all best placed on massive storage. For this, Amazon S3 offers good performance for amazingly low prices (around two cents per GB). Paperclip will ease the integration into a Rails app.

Encoding

Services like YouTube and Vimeo let users upload video files that can then be viewed in the web browser. Implementing this functionality in an application is easy with Panada. Pricing is expensive (starting at $100 a month), but a free developer sandbox lets you try out the service. 

Telephony

Need an application to be able to answer the phone? Want to notify your users of events by SMS? Setting up a PBX to do this is daunting. Using Twilio or Tropo will accelerate development time by giving a simple XML web service making and receiving calls or SMS. Both services offer free trial time for development.

Thinking about Migrating?

Unlike the featured caribou, I hate migrating. More specifically, I had migrations in web development; especially in Rails.

Here is why:

1. Migrations are used throughout the development process when they are only required after having deployed to production. Who cares if you loose data while developing?
2. Migrations duplicate functionality that every good software developer uses: version control. SVN, GIT and Mercurial are all great at revision tracking and the duplicate functionality offered by migrations is unnecessary.
3. Migrations make it difficult to identify what attributes a model has. Instead of defining everything within the model, developers need to refer to the schema.

Hating migrations leaves few solutions. My favourite is switching to a schema-less database like MongoDB (free hosting at MongoHQ) and then adding model integration to Rails with Mongoid or MongoMapper. This unfortunately is not be practical in many cases. For a less drastic solution try DataMapper.

Snow Leopard Rails Development Environment

A good Ruby on Rails development environment needs a few things: SSL, image processing, text editor, version control, etc. These notes explain how I setup rails development environments for Mac OS X 10.6 (Snow Leopard).

Step 1. Updating Gems

Before doing anything, it is important to ensure that you are running on the latest gems. To do so:

sudo gem update --system
sudo gem update

Step 2. Enable Web Sharing

Enabling web sharing will startup Apache. To do so ensure System Preferences > Sharing > Web Sharing is selected.

Step 3. Configuring Passenger

Passenger allows for ruby applications (and more specifically rails applications) to be deployed to a Apache and Nginx. Since we just enabled Apache, we can now install it:

sudo gem install passenger
sudo passenger-install-apache2-module

This command will print instructions for finishing up the configuring of passenger. Follow them. You should then be able to run the following command as a test:

sudo apachectl configtest

If everything is good, it should print out “Syntax OK”.

Step 4. Enabling SSL

Apache does not have SSL enabled by default. To enable it uncomment ‘#Include /private/etc/apache2/extra/httpd-ssl.conf’ in ‘/etc/apache2/httpd.conf’. Next we need to generate our certificate:

cd /etc/apache2/
sudo openssl genrsa -out server.key 1024
sudo openssl req -new -x509 -key server.key -out server.crt
sudo chmod 600 server.key server.crt

Again run:

sudo apachectl configtest

And look for “Syntax OK”.

Step 5. Install Port and Image Magick

ImageMagick is required for image processing in some ruby gems (paperclip). To setup, first download and install the latest version of MacPorts from here. Then:

sudo port install ImageMagick

This command takes a long time to run (thirty minutes to an hour). Once it is finished, Apache needs to know about the new binaries. This is done by creating a new file ‘/etc/apache2/other/port.conf’ with contents:

SetEnv PATH /opt/local/bin:/opt/local/sbin:$PATH

Again test apache.

Step 6. Setting Up Hosts

We made it! Now to create our first application. First, we want to map the host name for our application to our development computers IP. The sample ‘/etc/hosts’ file shows the settings required for setting up ‘http://dev.ksylvest.com/’ and ‘http://dev.kwik.ly’:

Next, browse to the directory ‘/etc/apache2/users’ and open the current user’s configuration file (for me ‘/etc/apache2/users/kevin.conf’). Attached is a sample configuration file for the above two applications stored in ‘/Users/kevin/Sites/ksylvest.com’ and ‘/Sites/kevin/Sites/kwik.ly’ respectively:

Again run:

sudo apachectl configtest

If you don’t already have a rails application setup, you can create one in a few steps:

cd ~/Sites
rails ksylvest.com
cd ksylvest.com
rake db:create
rake db:migrate

Then restart the web server:

sudo apachectl restart

Open a browser and test the web application by browsing to the URL specified in the hosts file. The server should also respond to SSL connections after you accept the certificate.

Step 7. Tools

Developing rails on a Mac is great because of the large number of tools available. My favourites include: TextMate, Versions, Git, CSSEdit and Adobe CS4. Some online services exist to help with version control (see GitHub and BeanStalk) so don’t setup local repositories if you can help it! Finally, ruby has many great gems and plugins for simplifying complex tasks in rails:

• paperclip
• authlogic
• searchlogic
• formtastic
• cucumber
• activermerchent
• prawn
• will_paginate
• shoulda
• heroku
• sll_requirement
• prawnto
• country_select
• acts_as_list