2008-06-06

Rails, Git, Capistrano, Ferret, etc... I'm exhausted.,

In the past weeks I've been trying to get my application to play nice with the latest of the "Rails-stack". This includes Rails 2.1.0, Git, Capistrano 2.3.0, Ferret (and acts_as_ferret) with the DRb server, running under Phusion Passenger, a.k.a mod_rails under Apache 2.
I must say that the only thing here working 100% as advertised is Apache and mod_rails. Thank's so much for that! Wonderful!
Let's start from the top. Upgrading to Rails 2.1.0 wasn't much of a problem, just annoying trying to get all the gems and plug-ins to play nice. I don't know if it's good or bad to prevent Rails from running without the gems declared in environment.rb. The biggest problem I had was with the datetime_toolbocks plug-in. It seems that the author isn't that bothered with updating the code to run with Prototype 1.6.x which ships with later versions of Rails. So I've reverted my Prototypes back to 1.5.x for now. Don't get me wrong, I appreciate the fact that the author has (without much acknowledgment to the original code of Dynarch's Calender) packed it up and distributed it. The functionality is pretty much spot on, and I initially wanted the Dynarch Calender as I've been using it before. What I don't like is developers being incommunicado and not providing updates (not requesting features here). But hey, it's free and I shouldn't look a gift horse in the mouth. It still took me hours to figure this all out.
All well, I was running on Rails 2.1.0. At this stage Git was working quite well after my initial problems. Now I needed to work out how to get Capistrano to like Git and how to configure it all on the server. This proved to be a task of trial and error because I just can't find any good Capistrano documentation, I also don't like the default Capistrano working layout that assumes you trigger your updates from a third client (in addition to SCM server and deploy-to-server). But that's another story and I do have my reasons. In my head I want to log into my SCM server and trigger the update from there. I also don't like the default set up of using SCM updates to get the latest source to the server. In my head (again) the server should have a minimal install, and a source code management software does not belong on the server. Luckily I can easily change Capistrano to pack up the code and copy it over to the server instead. Sadly I got lured into using both remote-cache and local-cache. I can't even remember what was wrong with remote-cache, but I stopped using it. Local cache had two issues, both not related to Capistrano. First one had to do with the fact that I wanted the local cache to reside on another partition than my temp partition. This was a bad idea because Capistrano uses hard links to copy the code over to temp and then tgz the code up. And as seasoned Unix users know (i.e not me before this) a hard link is basically the same file, and the same file can't exist on two different disks. So after a few hours on that issue, I moved the local cache to the same partition as the temp dir. After this I noticed that local cache has got issues with, erhm... caching. It doesn't seem to recognize permission changes and perhaps file changes. This could be an issue with Git, I don't know, and I can't be bothered to care. I simply ditched the cache; Bandwidth to the people!
If you're a seasoned developer/sysadmin you'll feel in your gut that my problems with caching resulted in "other problems". One naturally assumes that when you update your code, you get new code. So I've spent hours trying to figure out why things aren't updating as they should.
And then we come to the Capistrano recipes. *sigh* I find Capistrano terribly difficult to debug because the output is so vast. Once I had a basic set-up working I got stuck in trying to get Ferret working with Capistrano. This seems to be a fairly known issue, and to some degree fixed in SVN (why it's not released, I don't know). Needless to say the instructions aren't that clear, and it took me ages to get to where I was. My tip is to basically apply the patch and you should be half way there. Notice that if you do it manually, save a few hours by noticing that line 39 is deleted. *sigh*. I'm not the only one having been frustrated by this. On top of that I've done some 25+ commits into Git to try to resolve this (I refuse to code downstreams, i.e on the deployment machine in my case).

It's difficult to describe how deflated I am after all this, especially without sounding ungrateful. I can understand that some people feel the need to do rants about Rails' stability and community. Personally I guess I just have to come to terms with the fact that the Rails environment is filled with people from most spectrum, but probably overpopulated with young people who have a huge energy (which I don't want to belittle), but also that these same people have got little experience in the commitment that one makes when one writes software. Software has got a nasty tendency to linger way beyond its "best before"-date. (For those who know me I can provide this acronym to get you nauseous: HMS1). It is probably this fear of commitment that has resulted in my lack of contributions as a software developer to the world.
I'd like to communicate a few points to the contributors to the Rails environment; 1) I'm not interested in writing a f***ing blog. 2) I'm not f***ing interested in writing another f***ing facebook/twitter/myspace/social-networking/site. 3) In fact, I'll let you in on a little secret, the world needs another blog software or another social networking site like it needs another PHP DB abstraction layer, or indeed, you need another hole in your skull. Just say "no", please. 4) The application I'm trying to write is a corporate level application, I need data integrity, you know, enforced foreign keys, subqueries, transactions, and so forth. I don't care if Rails can handle it without those fancy-pants database features, but I need my data to be sound, regardless of where it's being presented. I want this requirement to be reflected in the code and the software I use.
When I install a plug-in, or indeed, Rails, I naively trust that the code I'm installing will have some sort of backing, and if it doesn't have the backing at least I'd like to know that there's no support - preferably in big red bold letters.
I'm just very happy that the era of Mongrel Clusters seem to be moving into the past. Something we can all, hopefully, point and laugh at in a few years, when our mental wounds have healed.

Just to top things off, here's what deflating my enthusiasm even more; I'm only half way through. I still want to create a deploy-to-multiple-servers Capistrano, and then I want to wipe the staging machine clean and document the installation step by step. Just to make sure everything works.
But right now I just feel like getting a bottle of Finlandia and crawling into a dark closet and not come out before the bottle is empty...
... but that would be counterproductive (even if I'd support the workers of the vodka factory), so I better get on with some more ghettoing! ;)

No comments: