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.

Originally, I was going to start with Chapter 1, but then I thought, what the hey, why not start right off with some criticism. Mild criticism, but criticism none the less.

In The Rails Way - Introduction, Obie goes out of his way to talk about Enterprise Adoption, and how well suited Rails is to improving the lot of the enterprise developer. I happen to agree. Having worked on a lot of projects, in a lot of enterprises, I have a good idea how much improvement, and it is significant.

On the other hand, Obie also goes out of his way to not-so-subtly snub Windows users. Given this pro-Enterprise, boo-Windows attitude, I'm going to guess that Obie didn't attend the Enterprise Rails BOF at RailsConf 2007. Actually, since I was there, I'm pretty sure I can say that he wasn't. That particular session sticks in my mind for two reasons. First, I was the one and only woman in the room (surprise, surprise). Second, and more significantly, I was the one and only Mac user in the room. This should not come as a surprise. Enterprise developers tend not to have a choice about their development platforms. Corporate policy, in all the large corporations where I have worked/consulted (Shell, IBM, Halliburton, IHS to name a few), dictates that there is one corporate computer flavor and that flavor is Microsoft Windows. Now, some of these enterprisey guys at the BOF had branched out, with VMWare installed, and were running Linux in order to do their Rails development, but frankly, that's a hack. If you are a developer, you want maximum power out of your development platform and tools, and running in a VM is unsatisfying. IMO, if Enterprise developers are going to make any impact on the numbers of Rails developers, it's likely to be as Windows users.

And this of course is where 3rdRail comes in. Right out of the box, 3rdRail comes ready to run on Mac, Linux and ... Windows. Delivering a fully operational Ruby/Rails environment, including database, 3rdRail enables enterprise developers to get the most out of their native development platform. Since most enterprise developers will also be IDE users of some persuasion, 3rdRail should be a familiar experience, especially for Eclipse users, because 3rdRail is based on Eclipse.

I got my copy of Obie Fernandez' The Rails Way a couple of weeks ago, but I've been so busy with work (we're down a sysadmin, a web designer, a tester, and now a developer... sigh), that I just dropped it on a shelf and almost forgot about it. Today our new sysadmin started, so I had a little breathing space (ha!). Another coworker/developer, Hal, reminded me about the book by pointing out that we'd met one of the contributors at RailsConf 2007 last year. Hi Jodi! Thanks for helping me debug our production Rails app during one of the sessions!

Anyway, I turned off the TV tonight, and pulled out The Rails Way. Since I've been using Rails for over two years in a quasi-enterprise application, I'm not expecting a tonne of grand revelations, but I'm certain that there will be a lot of tips and tricks that will improve my Rails usage, and my understanding of Rails internals.

As I started reading the introduction and chapter 1, it occurred to me that there was something else quite useful I could get out of this book. I've been nagged (in the nicest possible way) on and off for months about blogging about CodeGear's 3rdRail, which I use every day in my Rails development. Turns out, as I was reading, I kept thinking stuff like... "oh, yes, but in 3rdRail it's even easier to do..."

So, that's what I'm going to do. Chapter by chapter, as I go through the book, I'll be posting about the ways in which 3rdRail makes my life easier, as an enterprise Rails developer. Expect the first installment before the end of this week. I look forward to hearing what you think, so gimme some comments as I go!