Ruby Update

Remember that post I wrote about my adventures in installing Ruby?  The one I JUST wrote?  Turns out all of my struggles were unneeded.

You see, one of the reference books I was using is called RailSpace, and it attempts to teach already experienced programmers how to use Rails by building a small social networking site from scratch.  I thought it was a great concept, and I enjoyed what I was reading.  The book's use of Ruby 1.8.5 and Rails 1.2 was the driving force behind everything I slogged through.  What's worse, after finishing that last post, I still couldn't get through the book due to version mismatches between Ruby/Rails/Rubygems/whatever else.  I was completely hosed, even in triumph.

Yesterday, I googled the RailsSpace book to look for guidance.  Often times programming books have a dedicated websites with updates, sample code, and sometimes even message boards.  I thought I might find that someone had the same struggles years ago when the book was new.

Guess what the first Google result is when you search on "RailsSpace"?  It's called the "Ruby on Rails Tutorial", which alone doesn't sound like much.  What it REALLY is is an updated version of the RailsSpace book, created by one of its authors, Michael Hartl.  While it isn't entirely the same, it still has you making a social networking site using Rails, and it is written in the same style and pacing as the book.  I've already begun to work through the first two chapters, and I've yet to encounter a single hiccup.

If I had known about this site a week ago, I could have saved so much time and stress.  If I had to pick a silver lining out of the storm clouds, I'd say that I still learned quiet a lot in my failures.  I just don't know if it was worth the overall time spent.

No use crying any more over spilled milk I guess.  Time to do something productive.

Ruby on OS X

A few weeks ago I decided to try (once again) to learn Ruby and Rails.  In the past, I never got far in this endeavor, on account of getting confused and/or bored. This time, I haven't gotten far because I haven't been able to get the damn language working the way I need it to.

Allow me to elaborate. I am using several pieces of dated but still useful reference material.  The good thing is that they were all published around the same time, meaning they all use the same (or similar) version of Ruby, Rails, and Rubygems.  The bad thing is that all of these tools have received major upgrades in the years since.  Version mismatches usually lead to incompatibilities, and sure enough, the commands listed in my Rails book are flat out broken when used with Ruby 1.9 and Rails 3.  I needed the old stuff, and I needed it configured properly.

My quest to to achieve this perfect development environment was a monumental pain in the ass, redeemed only by the fact that it taught me a ton about Ruby, the Ruby community, and the innards of OS X.

My first major hurdle came while trying to compile Ruby 1.8.5 from scratch.  It turns out that as of Mountain Lion (or maybe Lion, I forget), OS X has no pure version of GCC.  It's all LLVM, with either a Clang or GCC front end.  Suffice to say that only the most bleeding edge version of Ruby compiles nicely with these tools.  Everything else simply craps out at one point or another.   At this point, I decided to look for some alternatives.  RVM is a popular tool for managing different versions of Ruby, so I tried to give it a shot.  It failed spectacularly.  Unbeknownst to me,  RVM installs different versions of Ruby by compiling them.  Obviously it failed just as hard, no matter which version I tried to install.

I went back to the Internet to look for solutions.  The most common suggestion was to install Apple's pre-Lion version of GCC4.2 using Homebrew.  I don't like Homebrew (or Macports or Fink), and I wasn't excited about using it just for the compiler I needed.  So instead I found a wonderful guide to building GCC from scratch on OS X.  The instructions worked perfectly, and they left me with a working, up to date compiler that was installed to a sane location.

I didn't know it yet, but at this point, I had all the tools I needed to get Ruby up and running.  Yet I still struggled when building from source.  One issue is that the Ruby source has some glaring issues (at least in version 1.8.5).  For example, I found one file that had #define where it needed #defined,and another which tried to pass a const char* to free() (which, at least on my system, requires a void* argument.  Then there was the file which defined two constants which already existed in OS X's version of stdlib.h.

The second issue was getting make to use my hand build version of GCC.  It was easy enough to put it on my PATH, but that wasn't enough.  Some parts of Ruby's build process use the generic cc command, and on OS X this is a symbolic link to /usr/bin/clang.  I only discovered this last part today.  A week ago, I had what looked to be a working version of Ruby which failed to install gems.  When I googled the error messages, all of the hits were concerning the aforementioned issues with compiling Ruby using LLVM and Clang.  I kept thinking "but I'm not using them.  I have GCC4.7.  I can see that it's being used by make. "  Only it wasn't being used by make. At least, not during the entire build process.  When I finally changed the cc symlink, the build finally succeeded.

Just kidding.  It failed again.  For whatever reason, several of the modules in the ext/ folder of the source tree had empty Makefiles.  I'm still unsure as to how this happened, but the issue went away after running make distclean, and then another make.  This time, I had a fully working copy of Ruby 1.8.5.  After that, everything fell into place.  Rubygems. Rails 1.2.  It's all working fine, as do the book examples.

At first, my takeaway from this ordeal was that Apple was doing a fine job fucking up OS X as a legitimate environment for programmers. By the end of it, my tune changed.  I still don't like the loss of GCC (and now I won't have to worry about it either), but if FreeBSD can get their system running with Clang and LLVM, I hesitate to say that either tool is a problem.  Rather, the issues seemed to stem  from the way Ruby is/was written.  I'm not saying it isn't worthy of being used in production environments, but I don't expect (and don't encounter) such sloppiness in any other major programming language.

I also learned a lot about the Ruby community.  Specifically, I decided that the concept of "convention over configuration" espoused by Rails developers extends into the community at large.  Did you know that RVM will change the way the cd command behaves on your system?  Even if the change isn't problematic for 99.9999999% of users, it is still something I'd like to be told about at installation.  I also grew frustrated at how so many of the proposed solutions to my problems boiled down to using a tool that would automagically download and configure the tools I needed in order to build and install the tools I wanted to use.  In other words, they wanted you to paste a few commands into a shell and hit enter, regardless of whether or not you knew what it would do to your system. To be fair, this isn't exclusive to the Ruby community, but I grow tired of it in general.

Don't worry though; I still have a Ruby specific gripe.  Before I installed Rubygems, I had a sneaking suspicion that the latest version would not be compatible with old versions of the language.  This is in fact true, but good luck finding this information out on the Rubygems homepage.  It may very well exist, but the only place I found the answer was an old question on Stack Exchange. Without that hunch, who knows how much more time I would have spent struggling.

Ruby'ers - I get it.  I really do.  Configuration sucks.  It's boring, error prone, and compared to writing actual code, is no fun at all.  But dammit, sometimes it's necessary.  If you ignore configuration, you will have no idea where to look when something goes wrong.  And despite the fact that these languages and frameworks ask us to trust them, they can and will make mistakes.  The only way to deal with them is to know what the heck is going on in the first place.

Core Image Fun House on Mountain Lion

All in all, I'm torn on what I think about OS X Mountain Lion.  If I'm lucky, I'll write a more detailed post explaining my personal pros and cons, but this post has to do with one of my biggest cons - the loss of Core Image Fun House (which I just wrote about in my last post).

The problem stems from Xcode 4.4.  It seems that Apple made some major changes to the IDE since the last version I had, including removing the /Developer folder, which was where Fun House, along with several other utility apps, resided.  The other utilities were retrievable through optional downloads from Apple's Developer site, but none of them seemed to contain Fun House.  I scoured Google for some sort of answer, and was able to confirm that it is, in fact, not being offered with newer versions of Xcode.  I still have no idea as to why, nor have I found anyone else who's wondering where it went (which was a reminder that the Internet doesn't always pounce upon every single change in the state of the world).

Thankfully, I did manage to find a solution. Fun House is an incredibly simple program, and it looks like Apple used to include it as sample code back with Leopard.  The code is still archived, meaning you can build it yourself a fresh copy of the executable.  Here are some general steps on how to do so:

1) Download the source code from the above link (look for the button labeled "Download Sample Code").

2) Unzip the archive, and open the project in Xcode (you should just be able to select File -> Open and open the folder itself).

3) Once the project is opened, it isn't runnable right away.  If you're on Mountain Lion, you're going to have project configuration errors to resolve.  If you click on the yellow exclamation point in the top-center of the IDE, it should bring up a list of errors in the left hand column.  Here's an image of what you should be seeing:

4) Double clicking on the second of the two errors will allow you to fix the settings.  You'll get a popup stating all of the changes Xcode will make.  It will look like this:

Click "Perform Changes".  If you get a message about enabling snapshots, choose whatever option you want.

Once the changes are made, the code should be runnable, with one final caveat. You have to run Fun House as a 32 bit app, rather than 64.  Most likely it'll be set to 64 bit by default, and you'll need to change that. In the top left corner, near the run button, you should see the something labeled "Fun House -> something something 64-bit".  Click on this to change it to 32 bit.  Then you can hit the run button.  If all goes well, Core Image Fun House will launch.

If you get a successful launch, you can move on to the final step - creating a .app file that you can run when you're not in Xcode.  In the left hand column, if you select the little folder icon, you'll get a resource view of your project.  Under the products folder, you should see the .app file.  Right click it, select "Open in Finder", and you can then copy the file to wherever you'd like.