I ran into a situation this week where I had a single partial containing form fields being rendered for different models. Inside that partial, one of the fields was a text_field_with_autocomplete, which presented a problem, since form_builder doesn’t know anything about text_field_with auto_complete, and the text field certainly needed to know what model we were working with here. After a little digging, turns out form_builder exposes a getter called object_name:

<%= text_field_with_auto_complete f.object_name, :city_name, ... %>

Easy.

A big topic at railsconf this year was hosting , deployment and scaling of apps. Talks and sessions on these topics were everywhere, not to mention Engine Yard getting pimped left and right (No, I won’t wear your tshirt). I found it extremely ironic then, when Michael Koziarski said in the closing keynote (paraphrased):

Deployment is a word you shouldn’t have to know.

I couldn’t agree more. I want to be as removed from the details of how to deploy and scale an application as possible. I want to focus on writing software that meets my customer’s needs, and the rest is details.

I think mod_rails is a big step in that direction. I think those guys are awesome, but I’m certainly not interested in writing improvements to garbage collectors to make ruby faster. It’s just not my bag. The more time I have to spend worrying about and managing deployment, the less time I’m spending “investing in myself” as DHH put it, and solving problems for my customers. It’s good to know that there are smart people out there working on how to scale applications, but I just don’t want to have to concern myself with it. Most of the apps I write are pretty small anyway, and when I meet the need to seriously scale, I’ll pay someone else to do it. Software like mod_rails is allowing me to survive even longer on a VPS (we use slicehost) so I can spend my time doing what I do best.

I moved my first VPS hosted slice over to phusion passenger (aka mod_rails) last night and was pleased so see the memory usage on my slice immediately drop about 15%. However, this morning I had lots of cryptic error messages about ruby_inline as follows:

Permission denied – /var/www/apps/mysite.org/releases/20080528201859/tmp/.ruby_inline/Inline_ImageScience_aa58.c
/usr/lib/ruby/gems/1.8/gems/RubyInline-3.6.7/lib/inline.rb:731:in `initialize’

I had already dealt with this issue when first setting up imagescience, and this looked related, but slightly different.

What I didn’t forsee was that previously, my mongrels were started with sudo – therefore running as root. When running with passenger, the user www-data was now the one that needed write access to the tmp directory, where rubyinline is doing its thing.

A quick permission change, then a restart with touch tmp/restart.txt and everything was green.

Overall, I’m really happy with the ease of setup and performance of passenger so far.

Hot on the heels of RailsConf, I’ve decided to do something I’ve been meaning to do for a while, which is start a blog centered around rails, software, and business issues related to each of those and the rails community.

I’m going to start with some impressions and opinions I came away with at rails conf, coming up next . . .