Kevin Sylvestre

Setting Up Mac OS X Lion Development Environment

curl -L goo.gl/8wiSB | bash -s stable

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.

Are Grid Systems Wrong?

I am currently in the process of finishing up a project and have started to question the ‘correctness’ of grid systems. Although they are extremely powerful, I see a number of flaws (this discussion targets the 960 Grid System):

New Markup

Grid systems require the introduction of new markup into the HTML (adding ‘grid-2’ to class variables, etc.). This is especially bad HTML to inject because it is non-semantic (adds no meaning). A possible workaround is to switch to using smarter stylesheets with SASS and compass, however for many projects this isn’t an option.

Annoying Layouts

Grid systems rely on having ‘gutters’ between elements. Unfortunately this can make integrating with non grid system elements a pain. One solution is to switch to using a more precise grid system (Blueprint CSS offers more granularity and fixes some of the gutter issues).

Commitment Issues

The last criticism of grid systems pertains more to design decisions. Once a designer (or developer) starts using grid systems they get hooked. Just because the grid system can format a beautiful about page, does not mean it should be used within the core of an application.

Conclusion

Although the above issues are serious, life is much better with grid systems. Use them, but use them carefully.

OptiPNG

I recently needed a small project to test out Platypus, a tool used to create simple native Mac applications. After only 30 minutes I managed to create a container for OptiPNG, a PNG compression library (download DMG or Zip). The icon was found on Icon Finder and was designed by Louise Harobe. The DMG was created using DMG Canvas.