Nested Layouts in Rails

I was wondering how to keep the layouts in my rails application code DRY - I was close to the point of kicking myself for having to make changes to all my layouts whenever something standard changed - so i researched online and found the above diagram by Matt McCray in his blog.

I used Matt's method for nesting layouts, but instead of defining a method called sub_layout in my controllers, I called a pre-defined rails controller method:

<% render :partial => "layouts/#{controller.controller_name}" %>

and defined a partial layout named after every controller I had, which had different settings for their own views. Rails has a local variable called 'controller' you can use to access its controller's name and even the action used for the current view. So using this, I don't have to define additional methods in my controllers, nor use any plugins.

kudos to Matt for coming up with this in the first place. Thanks!

Pair programming explained!

Here's the slides I used to explain pair progamming to my peeps - whew!

Pair programming looks like fun. We'll be doing it next week, so more on this later!!

Before I forget (and I do it a lot), here's the link to the file

Pair Programming - I Drive, You Show the Way

Ever gone on a road trip - alone? Not much fun is it? With a Big Mac in your mouth, you've got to have one eye on the road, one hand on the steering wheel, the other eye on a map, and the other hand clutching it. Now that's a feat even unicycle riding, ball juggling circus clowns find hard to do.

It's the same thing with programming - on the one hand you've got to make sure you're codes are syntactically correct (never mind politically), and on the other, you've got to think about software and database design, security, speed, scalability and a whole bunch of other issues. Now i know most of you out there can do this better than a circus clown, but the fact remains - wouldn't it be better if there where a 'co-driver' so to speak?

Here's where pair programming really shines. I used to think pair programming was just a bunch of 'poppycock' - two people sitting working on a single computer one the same set of codes - whatever for? So they both can slap the sense out of each other if one decides to snooze?

It turns out that, when explained the 'co-driver' way, it makes a lot of sense. When I do programming, and I reach a design decision point, I tend to stare off into space for a good few minutes while the cogs in my brain turn (rather slowly, I might add). It's kinda like stopping at the side of the road to refer to your map to decide which way to go (if you're alone of course). Having someone else figuring out the way, just makes more sense.

Ok, enuff explaining - I'm preparing training slides for this to start pair programming in my team - slides for this next post!

Rails 2.1 script/dbconsole

It's been a while since i posted anything up on this blog. Meanwhile, our programmer fadhli, has been busy - in the right way of course.

Here's a link to his own blog for a post that talks about rails 2.1's new script that helps manage your database...

And i promised some posts on agile methodology last week... shame on me... one coming up next week!

Global Email Settings in Rails

I was running the functional test and didn't realize it was sending actual emails from my data fixtures. However, I did learn how to globally set the email settings so not to send the emails out during tests.

If you want to use this, create a file called global_email_settings.rb (or whatever you want to name it) and put it in your your config/initializers/ folder. Restart your server to get rolling.

begin
  unless ENV['RAILS_ENV'] == 'test'   
    ActionMailer::Base.delivery_method = :smtp
    ActionMailer::Base.smtp_settings = {
      :address => 'smtp.domain.com',
      :port => 101,
      :domain => 'domain.com',
      :authentication => :plain,
      :user_name => "",
      :password => ""
    }
  end
end