I have a project coming up that would probably be a great Seaside candidate. The database has to be postgresql (according to the client). There is a native cocoa component – I’ll probably give BaseTen a try. For the web component, the obvious candidates are Rails (although I don’t know the state of Rails with PG – only mysql), and Seaside/Glorp – but I need to use Glorp to work like Active Record since the DB will be the master source of record for the schema.

Sadly, it doesn’t look like Glorp’s ActiveRecord on Squeak is ready for prime time, I might have to kind of finish that implementation.

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.

dot notation vs non-dot notation. When to use which?

collection.select {| x | x > 5 }

vs

collection select {|x | x > 5}

they both seem to work. Also, use of parens around argument lists – also seems to be optional. Two different block definition syntaxes is also annoying.

Less syntax would be most welcome.

I mean, I can only learn so many frameworks at once. So here we go – working through Agile Web Development with Ruby on Rails.

• A simple content management system with blogging capabilities
  • Manage your entire site from the web
• A simple shopping cart that’s tied into Authorize.net (must have an account)
  • Live real-time shipping rate calculation via FedEx? (must have an account)
  • More payment processors like Paypal and 2CheckOut coming soon
• Product and order management
• A stunning administration interface
  • Create and maintain content
  • Create, maintain, void orders
  • Answer questions from your visitors

We seasiders need to get moving and do something similar.