And I hate magic. First, I confess that I probably still don’t have a full command of all ruby’s features – I’m just getting the hang of mixins and some of the wacky compositional capabilities.
I’ve just deployed my first soup to nuts rails application. Well, nearly. It certainly starts fast. Generate ActiveRecord classes for your tables using scripts and you’re off and doing basic CRUD.
However, its the little things that made the experience less than satisfactory. First – the changes in behavior moving from development to deployment were nerve wracking. I have rails running under apache on my laptop, no problem. On my production server, I cannot get byte one to come out of rails. Webrick works fine. Mongrel works. Rails cgi produces no errors, and no output. Even apache logs are totally silent. I don’t get it. For now it is running under mongrel – but I’ll have to put that behind apache and front it using modproxy. Irritating as hell.
Second, I set up memcachedкомпютри втора употреба on the advice of friends and was going to use it for my session cache. But it turns out that objects don’t get saved in the memcached – apparently you can only store plist kinds of structures. Objects get dropped. I spent several hours beating my head against this using the usual hammer for this nail – require_dependency. However, after listing every blessed model class as a dependency, it was still dropping a collection of objects. Back to the file based session cache.
Another thing that drove me nuts is all the magic values you can’t use for attribute names. I inherited this database and admittedly a bunch of columns and tables are stupidly named – however I kept running into problems with collisions with ActiveRecord extensions.
Another thing – camel vs underbar lowercase. You generally specify relationships as lower case names, that ActiveRecord uses to infer a class name. For instance, you specify the relationship as purchase_order and it figures you have a class PurchaseOrder that keeps its data in a table called purchase_orders with a foreign key purchase_order_id. This can all be overridden, but understanding which form to use where got pretty trying.
Reciprocal relationships – at some level of circularity, ActiveRecord falls over with stack level too deep on save. It isn’t even a very complex graph that does it in. It became necessary to remove a bunch of back references to get a save to work properly.
Overall, I’d say towards the end I spent more time debugging magic gone awry than I did building application functionality. So I have to chalk it up as a real learning experience, but not one I’m looking to repeat anytime soon. The lack of decent debugging facilities was really crippling – especially coming from seaside. ActiveRecord is cool, but it isn’t trouble free. Doing basic inheritance was a huge exercise in wackiness I’m not eager to repeat. If I hadn’t had a big old mysql database to build on top of, I probably would have used seaside instead.
So enough slamming – its not all bad. One thing that helped a LOT was the discovery of ActiveScaffold AS is AMAZING! I was able to throw together a coherent admin interface with it very quickly – its customization options are very powerful, and in the end I think the back office app will be about 80% AS and 20% task oriented workflow. That’s brilliant. A data driven sensible ajax interface almost instantly. Very cool.
I may do more ruby apps, there are some seriously powerful go-fast kinds of technologies, but much of the time savings this go-round was lost to flukey behavior that changed from environment to environment, and really lame debugging tools.
Rails is definitely a very mixed bag.