Joe’s Amazing Technicolor Weblog

Continuing on in year-end odd-project mode, I’ve found myself poking around Joomla! for a client. After working with a variety of Perl, Java, PHP, Python, and Ruby projects over the last 10 years, it’s very strange to find an “open source” project where significant chunks of project-related code are in some way proprietary.

For example, the first calendar component that pops up on my searches is licensed under the GPL, but costs $5 to download. The authors explain that this all makes sense because the files for the component are available at joomlacode.org. Maybe yes, maybe no, but I think there’s good reason this isn’t a common pattern. The $5 introduces some friction into the whole system — while it isn’t a significant amount of money to exchange for something that’s going to save development time, it forces the developer to find their wallet, dig out their credit card, and type in a bunch of numbers, all sight unseen. Multiply this friction for everyone who might come in contact with the code, offer patches, bug reports, etc. I can’t imagine things working this way in any of the other open source project communities I’ve worked in.

The calendar certainly isn’t the only example; the only tag component I can see is a proprietary component, complete with a graphic of a software box and at least a half-dozen “Get your copy - Download Now!” (for £ 25.00 + VAT) links on its home page. A little searching reveals some interesting perspectives from commercial component developers.

None of this is to say that the Joomla! community’s approach is inherently wrong, but as a developer thinking about doing some work with Joomla!, I’m motivated to reassess other, more conventionally Open Source options.

I have a new project coming up that seems like a great fit for Ruby on Rails, particularly the RESTful interfaces that have gone in over the last year. However, the typical questions about using Rails apply here: I’m not sure how well the project’s hosting environment will support Rails, and collaborators aren’t as familiar with it. Thus, it seemed like it might be worth another look at options on the PHP side of things. I keep hearing that CakePHP is Rails-inspired and has many of the same advantages, so today I’ve taken the stable version (1.1.8.5850) for a spin, letting the Cake manual’s blog tutorial get me started. Here’s what I’ve noticed about CakePHP development as practiced in the tutorial — maybe there’s better ways to do things & the tutorial just isn’t mentioning them?

• 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.

Update: Looks like I would have done well to wait a day before upgrading to the 2.0 preview.

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.

I see that Seth’s blogging today about the benefits of using XSL as a template language. Another open-source XSL template system worth mention is the apache AxKit project, which we started using at the Walker Art Center in 2003 because our new designer Brent was already a fan of XSL templates.

Our first AxKit project was How Latitudes Become Forms. Since I moved, I understand that AxKit usage has been the standard for most in-house work.

One of the sessions at Boston’s recent Barcamp was on AxKit, so apparently there’s somebody in the area using it.

(this really should just be a comment on Seth’s blog, but it’s easier for me to write it here than to sign up for a blogger account, which is apparently now required)

I was able to make it to a good chunk of Barcamp Boston 2 this weekend, and learned some good stuff. Hats off to the organizers for putting everything together, especially considering the challenging weather conditions. Some of the things I picked up:

• OpenID is threatening to pick up enough adoption to be hard to ignore. Still looks like there are more producers than consumers, and I’m not comfortable yet that I understand the trade offs of delegating my ability to log into a wide swath of services (maybe YADIS could be helpful here?).
• Mapping has come a long way. In particular, OpenLayers is being used for some very interesting stuff, for example at the Open Guide to Boston. Advantages over the Google Maps API include openness and ability to do non-point features (like a bike path). Recommended tools also include Quantum GIS, described as something like photoshop on top of a mapping database. Massachusetts, it turns out, is a leader among states in terms of sharing mapping info (other good local resources include Harvard and the metropolitan planning council).
• New respect for the things that can be done with javascript. Including Alan Taylor’s encryption-in-your-browser project, John Resig’s jQuery presentation, the Open Layers stuff, and the guy in the CakePHP session who salvaged some laughs from Nate’s “starts with java” joke. jQuery seems like it’s worth a closer look - I like what I saw of the selector syntax, the ($document).ready(function) hook, and the fact that there’s a lively community and seemingly robust plugin system. Also some good pointers at the end of John’s session to the Selenium IDE, test.simple and Firebug Lite.
• Seems like there’s good potential for some kind of coworking arrangement in Boston. In the meantime, I’ll have to check out Sweet Finnish again.
• The Stata center is a fine place for this kind of gathering. It didn’t even leak!

After taking svk out for a spin this week, I’m having trouble thinking of any, beyond “it’s too hard to install because I don’t use a debian-based OS”. Not to say that there aren’t other OSes that it installs on easily, but I’ve only tried it on Ubuntu, which if course required only sudo apt-get install svk.
svk has some serious bennies:

• no more .svn files littered throughout working directories!
• we can keep committing away even when the svn server or network connection goes down, and then push all those commits to the server when things are working again.
• smarter merging (I think; haven’t spent much time with it yet)
• almost nothing to learn; for normal commands, just type svk instead of svn.

Not to say that all is perfect; the docs are a little thin & scattered. The most comprehensive seems to be the online book which is cribbed from subversion’s - in fact, a number of places in the book still read “subversion this & that” instead of “svk this and that”.

I’ve been working on a little Ruby on Rails application on and off for a few weeks, and finally have enough together that it made sense to deploy it somewhere other than my laptop. It ended up taking all day; here are some of the high and lowlights, in chronological order.

• 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.