This had me screwed up for hours, trying to figure out why the ruby-ole gem was coming up as "not installed" but then it still worked. You need to specify a :lib for it.

config.gem "ruby-ole", :lib => 'ole/file_system', :version => "1.2.10.1"

Gem developers, PLEASE, if there is anything special/nonstandard about using your gem, PLEASE, mention in prominently in the documentation. I don't think that's too much to ask.

Twice, actually.

First, there was the, I think, Ruby 1.8.7 upgrade. Suddenly, my home-grown acts_as_my_thing plugin stops working. The classes with "acts_as_my_thing" crash and burn when loading, saying that "acts_as_my_thing" doesn't exist. Crap. Now what?

Eventually I managed to find the proper incantation. I have an abstract super class for a bunch of my models. It's called LabRecord. In the file that defines my "acts_as_my_thing", I had:
LabRecord.class_eval do include Lti::Acts::MyThing end

I think there is a class-loading chicken-and-egg problem going on, so after trying a bunch of stuff like moving around "requires" in the environment.rb file, I eventually decided that I was "doin it rong", and did this instead:
class LabRecord < ActiveRecord::Base include Lti::Acts::MyThing ...

But, that wasn't the end of my day. I did say twice, didn't I? A little while later I was diddling around with svn in my Rails project, and then BOOM. 3rdRail/Subclipse couldn't read my workspace anymore:
Unsupported working copy format svn: This client is too old to work with working copy '/Users/lori/Documents/workspaces/labrador/dev2'. You need to get a newer Subversion client, or to downgrade this working copy. See http://subversion.tigris.org/faq.html#working-copy-format-change for details. I'm too tired for this shit. Sigh. At least if you follow the link, you can download the Python script which will convert your Subversion workspace back to 1.5 (Snow Leopard has SVN 1.6), and get back to it.

I don't really blog that often. Even when I was going at full tilt, I rarely posted more than 10-12 times a month. So... I don't care about the pagination plugin anymore. I especially don't care when it involves 3 inter-related plugins, at different/conflicting versions!

So I took the easy way out, I'm afraid. Googling for alternatives, I discovered this example pastie, which gives me the month-by-month archive in the sidebar you see now.

See? Who needs pagination?

I've upgraded the blog to Mephisto 0.8.1 Drax. I would have been in serious trouble, had it not been for Rob Seaman's blog. Waves! Hi, Rob. Thanks.

It wasn't just a simple upgrade, in fact, it was pretty freaking complicated. But, since I worked so hard, it should be smooth sailing for the future.

1. Upgrade to new Mephisto, and learn more about Git at the same time (Rob's blog was really useful for that part)
2. Moved from Nginx/Mongrel setup on a Nitix box, to Apache/Passenger on Solaris 10 (SunFire V100). (More on that later)
3. Capified the blog, for better/faster customizations and updates. (Yeeee!!!!!)

Seems like a lot, doesn't it? I thought so too. There was even a couple of days of yak-shaving involved, as I attempted to force certain plugins to work, which were not compatible with 0.8.1. Never mind. The blog is up and running, and it will survive for a day or two without a tag cloud, or pagination. I'll get to it. Promise.

I'll be going to RailsConf next week, and (surprise), I'll also be speaking.
Discussion Panel: Women In Rails
Feel free to comment here, if you aren't going to the conference, but have any good discussion points to add.

I was having a lot of problems with my humongous Rails project lately, with a lot of long delays, build problems, hangs, etc. This all came to a head on Wednesday, when I couldn't do anything without having 3rdRail go and hang on me. But, one of my coworkers who also uses 3rdRail was not experiencing similar problems, so I had to come to the conclusion that the problem was... me.

I've been doing Rails development on my Mac for over 3 years now. This was pre-Leopard, so I had an installed-from-source Ruby that I used. I've been telling myself that this was just smart, because the Ruby that comes with Leopard now is subject to change, any time that Apple cares to issue a software update. I prefer to have my development tools under my own control.

Unfortunately, it seems that this custom Ruby install was the primary difference between my coworker and I, so on Wednesday afternoon I bit the bullet and ripped /usr/local out of my system (bye-bye custom MySQL, Apache, Ruby), and started the painful process of re-installing all the gems I needed using Apple's Ruby (yes, including the Oracle drivers and RMagick.... it wasn't a pleasant afternoon).

Well, now, don't I feel stupid... 3rdRail now builds/rebuilds my project in a reasonable amount of time, without all the stutters and hangs.

So, I'm posting this as an FYI. IF you run into build problems with 3rdRail, it might just be your Ruby install.

Our Rails application is very dynamic, so page and action caching are not really suitable. But page fragment caching is quite useful. I was implementing this yesterday, and using Greg and Ryan's very useful little tutorial, when I ran into a little difficulty...

Where the heck are the cached fragments?

It was puzzling, but I just couldn't find them, and I was going nuts searching. I thought maybe Passenger was overriding the default location, and stashing them somewhere under Apache. Nope.

Turns out, the answer is fairly simple. The tutorial was written some time ago, and since then the default cache store has changed from :file_store to :memory_store. So you can look for the cache files forever, but you ain't gonna find them.

So, if you want to see caching files in your development environment, you need to have these lines in your config/environments/development.rb file:

config.action_controller.perform_caching = true config.action_controller.cache_store = :file_store, RAILS_ROOT+"/tmp/cache/"

I was trying to do something elegant today, as I was patching a release, so that our new subdomain model would work seemlessly on the mobile version of our site. So, if people come in on the "wrong" subdomain, I want to redirect them to the "right" subdomain.

It seemed like url_for was the answer, using :overwrite_params:

new_url = url_for( :overwrite_params => { :host => host_with_correct_subdomain } )


Seems like that shoulda worked. Unfortunately, it's basically a no-op on the url, so I had to resort to a bit of regular expression goo:

new_url.gsub!(/#{request.host}/, host_with_correct_subdomain)


Not really elegant I suppose, but it works.