Let them eat CakePHP

[chipotle]

So I’ve been back at work and starting on a new project—actually, a re-implementation of an old one—for which I’m exploring CakePHP, a “rapid development framework” which is, shall we say, heavily inspired by Rails. Why not just use Rails, you may ask? Well, mostly because I’m the only person at the company who knows Ruby and I don’t know it all that well. (On the flip side, CakePHP’s documentation isn’t as good as Rails’ is.) Also, as many Hipster Points as Rails garners, it is neither easy to deploy nor lightweight when it’s running. (The currently-preferred method of running it is with a hybrid mostly-Ruby web server called “Mongrel,” which in practice tends to run in addition to a standard web server on a box. bigtig asked the reasonable question the other day of why it isn’t deployed with Apache and mod_ruby; AFAIK, it’s because mod_ruby used to have performance problems and a tendency to lose its brain if you ran more than one Rails application at a time with it, but I think those have been solved now.)

Cake does look like a well-designed system, although it’s occasionally an inadvertent demonstration that Ruby really is a more elegant language. (A language more elegant than PHP? Say it isn’t so!) To try to make sure what Ruby I’ve learned doesn’t get too fallow, I’m writing the script to convert from the old database format to the new one in Ruby; it’s not a straight one-for-one mapping, since I’m not only using column names Cake (or Rails) will like, I’m doing a bit of database normalization along the way, giving some data fields their own tables and index keys. So the script will have to build those tables and the relations. Not a huge thing, of course—just enough to remind me how much Ruby I’ve forgotten.

Also on the geek front, I’m taking Tuesday off next week to go to MacWorld, even though just to the exhibition hall, not the keynote. (I have a free floor pass.) In theory after that I’ll be trying to get to the Apple Store in San Francisco for a taping of MacBreak Weekly, hosted by former TechTV guy Leo Laporte and former friendly college acquaintance of mine Merlin Mann, who is one of the only people I’m aware of who seem to have made a career out of being an internet personality.

Meanwhile, Panera Bread marches ever closer to the house—they’ve opened a new location just across from the closest Fry’s Electronics, so I’m sitting here with a cup of coffee on their free wi-fi. In theory, though, I’ve come here to see if I can get some writing done on things other than journals (and Ruby code for work).

Comments

[higginsdragon.livejournal.com]

(On the flip side, CakePHP’s documentation isn’t as good as Rails’ is.)

Good lord, that IS pretty poor documentation. ;)

Also, as many Hipster Points as Rails garners, it is neither easy to deploy nor lightweight when it’s running.

I'll agree about the heavyweight part, Rails is very memory-intensive. However, it is amazingly easy to deploy and update when it is running. Code deploys are so short that if someone is reading a forum message, by the time they click reply and respond or next, the update is done. I liken it to the whole Matrix glitch thing. Something short happens, might be a small disturbance, but then things are subtly different.

Yay for capistrano! I can't think of any downtime more than 2 minutes for most code updates or deploys, the only ones taking longer things being database migrations that need to transfer/convert a lot of data.

Also, interestngly enough, because of the mongrel-apache combo, it is amazingly easy to scale as more power is needed. I rather like the way it works. In theory, I think, you could have mutliple machines with mongrels feeding one or more Apache servers. Not to mention, if there is a bug that causes a segmentation fault (something we found happens more than it should with acts_as_ferret) only one instance crashes, keeping X number running. Whereas if it was a single apache server with ruby_mod, it would take the whole server down when running into a single fatal bug.

I could never get into PHP, it always seemed obtuse and originally structured as a scripting language. Not to mention I could never really get into it's templating system (or any of the others developed for it.) I've taken to RoR like a fish to water, and like Tilton, I don't think I'd ever want to go back to trying to learn something like PHP.

[chipotle.livejournal.com]

Good lord, that IS pretty poor documentation. ;)

Yeppers. To give them a half-point back, I discovered the CakePHP API is reasonably well documented and whatever "automatic API documentation" system they're using for PHP to make it is, well, better than Ruby's automatic API documentation system is, which always makes me want to pound my head against the monitor repeatedly when I have to look something up in it. The problem with the CakePHP "Manual" is that it's apparently supposed to be the equivalent of "Agile Web Development with Rails" and it, uh, isn't. :)

I'll agree about the heavyweight part, Rails is very memory-intensive. However, it is amazingly easy to deploy and update when it is running.

My impression is that it's the "when it is running" part that's the key there. Once you've gotten it happy, it seems to stay happy.

My vague (and vaguely ironic) concern for my own potential Rails use is that the host Claw and Quill is currently festering on has hard process size limits, and from what I've read Rails/Mongrel processes frequently go over the memory limit they have set and get automatically killed. I describe this as "vaguely ironic" because the host I'm using is the one described as "the official Ruby on Rails host" on RoR's web page. :)

I could never get into PHP, it always seemed obtuse and originally structured as a scripting language.

If I'm remembering right, PHP started out its life as a series of Perl scripts, and even though it's become a separate entity its syntax is still very heavily derived from Perl. Both Perl and PHP support objects roughly the way a log bridge supports an Abrams tank -- if you're careful and go slowly you can probably get where you want, but it'll be ugly.

PHP doesn't have an intrinsic templating system; for the last project I was on at my current company we used Smarty, which is actually pretty well-designed once you get the hang of it. (Ruby's "Liquid" templating system, which I've seen integrated with Rails on occasion, is pretty similar.) By default CakePHP just uses, well, PHP, with a few helpers to make it somewhat less clunky. That's another place where Ruby as a language just comes out looking more elegant, though -- ERb is a lot less intrusive-looking when it's integrated with HTML.

[higginsdragon.livejournal.com]

The thing about RubyDoc (and the way rake doc handles it) actually can produce decent documentation if you follow the syntax properly, allowing for formatting and it automatically links references to classes and methods. (For example, if I type Image it will link that to the Image model, same for ImageController, etc.) I'd dare say that the documentation for JaxPad/ArtSpots is better than most apps, just because I'm anal and followed the spec. However, trying to find concise documentation on how to document is a little bit of a task. :)

My impression is that it's the "when it is running" part that's the key there. Once you've gotten it happy, it seems to stay happy.

Unless you're running acts_as_ferret. :P It has been the biggest headache on our site. Although it could be that we're running the newest version and development seems to be stagnant. Will probably try going to a previous version if things persist.

My vague (and vaguely ironic) concern for my own potential Rails use is that the host Claw and Quill is currently festering on has hard process size limits, and from what I've read Rails/Mongrel processes frequently go over the memory limit they have set and get automatically killed. I describe this as "vaguely ironic" because the host I'm using is the one described as "the official Ruby on Rails host" on RoR's web page. :)

Hee! We used another recommended host, Rimu Hosting, and ran into the same problem. A virtualized machine with 384MB RAM. Not only did it sometimes exceed memory, but the way their system handled it was to kill the process using the most memory, which in a few cases was mysql. D'oh. :) Not to mention other people using the other VMs would slow it down, especially during 12am EST when they ran whatever nightly process they did. 9-12am PST was slow. :P

We use a dedicated machine now, and oh it's so nice.

Regarding templates, I'm just speaking of .rhtml, and you're right, it's just easier to parse visually, to me at least, when adding dynamic code snippets.