Miscellaneous notes from the project:

• My environment is now ubuntu server 8.04, on slicehost. This project finally prompted me to upgrade from 7.10, which went very smootly — the long-term support releases of Ubuntu seem like the way to go for most server situations.
• How to handle the apache config? We have some php stuff running on this server, too, so the 3rd party ubuntu passenger package, which wants to use the worker mpm, isn’t the hot ticket. No problem, passenger’s default gem-based install is smooth as butter.
  This configuration also seems to require RailsAutoDetect off, which had the side benefit of letting me leave an existing mongrel-using configuration alone until I had a few minutes hours to upgrade it to rails 2.2.2, then switch it over to git & passenger.
• Slicehost has decent docs for this, in particular ubuntu-hardy-mod_rails-installation and ubuntu-hardy-using-mod_rails-to-serve-your-application & its comments.
• Capistrano mods for passenger
• This was also my first git-powered rails app, which proved a little challenging to get going with cap, but has turned out really nicely. Very fast deployments.
  Along the way, having a plugin as a git submodule proved to be more trouble than it was with, though I’m not sure if that’d apply to my final configuration, which involves checking the project out from the same server as it’s deployed on,  using the :local_repository argument to capistrano.
• This project helped me realize that having a deployed app as a public github project is more trouble than it’s worth, what with the various configuration informations that I’d rather have under SCM but don’t want to share.

P.S. github is way cool.

• Somewhat like Rails, there’s DB-independent schema definition! Big win here. Among other things, this lets you develop in SQLite and deploy in MySQL, which is a nice pattern. Rails’ awesome migrations aren’t here, so it’s not as useful and flexible a system, but it’s better than nothing for getting up & running.
• One big difference from Rails that’s clear right away: rather than building code dynamically based on the DB schema, thousands of lines of getters / setters / etc. are generated by the symfony command line tool. Makes sense for PHP, but it’s a clunkier development experience.
• There’s testing built in! It’s a bit of a PITA to do things like create a test database, and all the pieces for testing your models aren’t there right away, but still better than CakePHP. The aforementioned missing piece is available as a plugin. There doesn’t seem to be a straightforward way to get the propel-insert-sql task to run on alternate environments, so one must create the db on their own. I’m using SQLite, which is great, but my local environment somehow ended up with PHP having SQLite 2.8 while my command line is version 3 (macports at fault? what a step backwards from Ubuntu…). One port install sqlite2 later, and you can do sqlite data/test.db < data/sql/lib.model.schema.sql
• No console, which makes the tests even more essential, so it does seem to be worth the pain of getting them working.

Side note — already, on the basis of the previous post, I’m seeing a surprising amount of traffic from searches on CakePHP, Symfony, and REST. Clearly I’m not the only one looking for this kind of thing.

• No migrations; you have to generate the DDL on your own, both initially and for any subsequent modifications. Also, no model or controller generators. It’s definitely nicer to just do script/generate scaffold post title:string body:text; rake db:migrate and be off to the races — from Rails 1.2 on, those races include the whole REST business. To be fair, there is a one off reference to ‘bake’ scripts in the CakePHP manual, but no pointers on what those are, or where they live, and the website isn’t much clearer.
• No TDD. Woah. That’s, like, half the advantage of Rails — automated testing is right there in your face, and is firmly entrenched in the community.
• PHP code is not quite as elegant as Ruby. For example, generating a link to delete a post looks like this: $html->link('Delete', "/posts/delete/{$post['Post'][id']}", null, 'Are you sure?' ). Can you spot the syntax error? Probably you can, but it took me a good few minutes. The Rails equivalent would be
  link_to "Delete", { :action => "delete", :id => @post.id }, :confirm => "Are you sure?", :method => :delete
• A lack of the experiences baked into Rails. For example, after the Google Web Accelerator fiasco, it became common practice to make all links to destructive actions happen via POST, which can be done via link_to’s :method parameter. Compare to the GET-powered delete link above, straight from the Cake tutorial.
• I miss my vim & rails integration, which makes creating and navigating the various files a breeze. (Glad I went to the trouble of making that a link, as it got me re-reading the plugin’s about page, and I saw the parts about partial extraction and migration inversion, neither of which I’d noticed before)

On the upside, using CakePHP sure beats writing a CRUD-heavy PHP application from scratch. One of my current projects, a completely custom contact management application, would be in much better shape if it were using CakePHP instead of the project-specific ORM I cobbled together — I’m going to have to give conversion of that project to CakePHP some serious thought.

But is CakePHP a DSL for the web in the sense that Rails is? Not yet.

I’m giving the Rails 2.0 Preview Release a spin, and finding that upgrading an existing 1.2.3 app is not totally seamless. Hitches I’ve run into so far:

• Ran into the missing active_resource issue, discussed at kopongo.com.
• A bunch of tests failed due to the oddity described (and patched) in ticket 9525.
• My nested resource routes all broke. Before if you had urls like http://example.com/posts/1/comments you’d get routes like comments_path. Now, you don’t; you get post_comments_path. I did find the new `rake routes` output awfully helpful for debugging this one.

Not too bad for a fairly big version jump. Other than the aforementioned annoyances, it’s too early for me to say much about the improvements in 2.0. I certainly do like the prettier RESTful URLs, and the prospect of a working debugger was a big motivator.

• When building ruby from source on my Breezy xen slice, I ended up with no zip lib. Gotta download a way old version that says it’s obsolete. This is just one reason why package managers are worth having; too bad there isn’t an acceptable versions of ruby in Breezy. I did blow a few hours trying to upgrade to Edgy yesterday, but bad Xen things happened so I’m stuck on Breezy for now.
• Capistrano needs ruby’s openssl lib, which is part of the core, but if you don’t have the ssl dev libraries around, it doesn’t get built. So, rebuild ruby and that part worked.
• I’ve been using sqlite for development and though it would be nice for production, too, so I had to install libsqlite3-dev & the sqlite3-ruby gem. Started to think about making it work with Capistrano, via ideas here. But even when the permissions all seem to work ( as in the user running the app can write to the file with the sqlite3 command line tool ) rails is only able to read from it - pukes with a generic error when it tries to write. So, mysql it is. Thanks to migrations, switching from sqlite to mysql only took a minute. Cool.
• Not so clear on how capistrano knows what user to run things as - this seems like the main reference, but I’m having trouble finding everything I need in there. Probably need to dig around in the source.
• This app isn’t running on its own domain, and I had an unpleasant time with RAILS_RELATIVE_URL_ROOT & lighttpd. I’m running rails 1.2 RC 2 and haven’t had a chance to dig around the changelogs to see if there are relevant changes in there that would explain the headaches, which are that it only seems to work if you set it in routes.rb as discussed here. That’s lame because you can’t just have it for production then. A better approach seems to be just doing it in lighttpd except that the app doesn’t then write urls correctly.
• Thanks to this lighttpd configuration guide for pointing out that alias.url needs to be set as well for the public/ directory to be properly served in this kind of configuration.

In retrospect, I probably would have been better off taking easier paths with a few things - running the app on its own subdomain, and going right to mysql both would have saved me some trouble. There still would have been a number of annoyances but that’s par for the course deploying software. Definitely not as much fun as writing the actual application.