The last month has been quite a trip down the rabbit hole into the new reality of ruby on rails! The promise of a powerful and well designed web application framework was just too much for me to resist, so I decided to leave my own yawaf framework behind (though it has certainly served me well).

So I’m posting this entry for those just starting down this path so you can see what might be on the path ahead of you and what I did to make my way over the learning curve.

1. I purchased both the Programming Ruby and Agile Web Development with Rails books, and read them cover to cover. Both books are good. Dave Thomas really can write a good programming book.
2. I dove into finally wrapping my head around the REST approach, which I also knew I wanted to switch to and was part of the reason I choose rails in the first place. To this end I found this great tutorial: RESTful Rails Development which expands on and gives clarity to the REST chapters in Dave Thomas’s book.
3. Then it was time to install the creature on my PowerBook. The instructions in Dave’s book are pretty good, but the real place to go is hivelogic
4. Once I had rails up I got my feet wet by implementing the bare essentials of the two projects that are the reason for switching to rails: the MANA stats project and, of course, open money.
5. Since another reason for switching to rails was to be using an open source framework that others are well familiar with, and because open money is an open source project, and I want to get it out sooner rather than later, it was time to figure out where it should live. I find source-forge unbearably ugly, and though there are some other nice FLOSS platforms (launchpad, freshmeat), I settled on rubyforge for obvious reasons. So I spent a number hours learning my way around rubyforge (an instance of gForge) and setting up the open money project there. I realized pretty quickly that rubyforge is the right place to put up the releases of the projects and I may even use their svn repositories for a while, but gForge doesn’t cut it as a project development environment.
6. So there I was off into another tunnel of the rabbit hole, which project development tool. So many of them… I see that lots of people, including the rubyonrails folks themselves, use Trac. However, I read many accounts of how difficult it was to install and get running, plus, I really felt that I wanted my project management tool to be in rails, to thereby leverage all my learning curve. I knew also that I was going to be modifying it out the wazoo, so it didn’t make any sense to learn yet another whole system. Dittio for various php bug-trackers, etc. After more hours of research, my options were then down to three: collaboa, retrospectiva (which is a fork of collaboa), and devalot. The first two are much more feature rich. But I ended up choosing Devalot, after talking with it’s author, Peter Jones (who seems like a real great guy) mostly because it just feels better than the others, but also because I like where it’s headed.
7. Then I started to scratch my head about how in the heck I was going to deploy these apps. Yawaf is Perl base and deployable as plain CGI and works quite well for small sites. I’ve always known that I could switch to mod_perl if traffic increased enough to warrant it. Rails is another matter. You need to start out understanding deployment.
8. So I read all that I could find, and tagged the good stuff for your reading pleasure on delicious. Upshot for me is apache 2.2.4 + mongrel + mod_prox_balancer + monit (not mongrel_cluster). [Update, after many hassles with monit, I ended up going back to mongrel_cluster (though I may add monit in later to monitor the cluster). See this e-mail exchange on the mongrel-users mailing list for details.]
9. Then I realized that getting this to happen on my current VPS was going to be a nightmare, because it’s a DirectAdmin box, and getting apache upgraded to 2.2.4 was hard enough, but adding mod_proxy, etc was just not going to be doable while at the same time keeping it stable with my current apps live.
10. So, then it was deeper down the rabbit hole into investigating Rails Hosting companies! Finding a hosting company in general is a huge pain and it is so variable according to your needs. Mine are complete control, hence VPS. Upshot: the company I wanted to go with, slicehost, is only taking reservations, and can’t fulfill orders for a month. Yow. (By the way, here’s a great writeup on rails hosting, and more delicious tagging of rails hosting in general.)
11. So, now I’ve decided to do all this installation and testing of my future deployment environment on my basement Ubuntu server until slicehost comes through, or I find something better. For Ubuntu installation I’m taking some hints from these instructions which were missing one dependency for apache to compile for me (sudo apt-get install openssl libssl-dev). You may also want to check out this peepcode screen cast for another take on how to install the rails stack onto Ubuntu using deprec. It turned
12. Once all the components are installed, the next challenge is configuring them to work right for your particular rails app. Enter bowtie, also by Peter Jones. Though still in development, this little utility produces configuration files for apache to use mod_proxy_balancer, and also for monit to launch and keep your mongrel instances up and running.
13. Ok, so server is up and running, and I have a basic app on my development box, now I how do I deploy to the production server. Enter capistrano. Yet another learning curve. The trick is getting your deploy.rb script right to handle all the various problems… That will wait for a future post.
14. Then, back into coding, I’ve realized that I just have to bite the bullet and start to use all the goodies built into ruby and rails for doing test driven development. So I started doing some background reading on good TDD practices which led me to behavior driven development which of course is why I’ve been putting of using TDD for so long because it’s BDD that actually makes sense. Here’s a great article by Dave Astels on BDD in the Ruby context. And fortunately there is rspec, a great implementation of BDD that integrates well into rails. The tutorial in the rspec documentation is very good for understanding it, and here’s the tutorial I used to get started using rspec in the rails context. Which led me to another helpful post by Dave Astels.