Ruby Hoedown is coming

The South is getting its own regional Ruby conference: Ruby Hoedown. I like to think of Northern Virginia where I live as being in two worlds: 1. The southwestern most tip of the NorthEast and 2. the northeastern tip of the South. Take your pick. :)

Looks like it’ll be interesting to go to. It’s about 4 and a half hours away from DC in Raleigh, NC at Redhat Headquarters and it’ll be happening on August 10-11.

March 28, 2007. Ruby. No Comments.

NOVARUG Meeting next Wednesday - March 21st

I’ve been away at Advanced Rails Studio most of this past week. I just confirmed the next NOVARUG (that’s the NOrthern VirginiA Ruby Users Group for the uninitiated and yes you will have to go through the initiation ceremony - I think there’s a public renunciation of Java and .NET involved…) meeting will be:

Wednesday
March 21
FGM Building in Reston, VA
6:30pm - 9pm
free pizza and soda

Sean Mountcastle will be presenting CRUD and REST Rails development as well as some ActiveResource.

I will be again piloting the East Falls Church Metro to Reston Shuttle. It leaves at 6pm sharp. RSVP me at luis at luisdelarosa.com if you want a ride.

March 17, 2007. Rails. No Comments.

Quick and Clean Rails Code by Chad Fowler - a summary

The last NOVARUG meeting was great. I have been insanely busy since then, but felt remiss not posting anything about it. So here’s a short summary with more details to come as I get time.

Chad gave a great presentation that comes from his recent experience as being a Reviewer of Rails Projects. In short: there’s a lot for all of us to learn as a community to improve the state of the practice of Rails, we need to do more testing and we really need to know Ruby better.

To give his points a little more emphasis, I started to think of them as Chad’s Rules of Quick and Clean Rails:

Chad Rule #0 - Be zealous about testing. Do TDD. A lot of this can be driven from that perspective.

Chad Rule #1 - NO SQL IN CONTROLLERS!

Chad Rule #2 - Think of controllers where you script the interaction between rich business objects. Don’t go above or below that level.

Chad Rule #3 - You should only do 4 lines of code in an action. Don’t include respond_to and don’t include semicolons. Colons are ok however. ;)

Chad Rule #4 - Utilize Association Proxies.

Chad Rule #5 - Use before filters to DRY up your controllers. This is sort of like when you set variables in the setup method of unit tests.
But…when you start inheriting before_filters, you introduce a level of magic which can make things mysterious.
Use this to get around Chad Rule #3. lol

Chad Rule #6 - Make your own language. Create DSLs when you can.

Chad Rule #7 - Use with_scope wisely.

Chad Rule #8 - NO (imperative) CODE IN YOUR VIEWS!

Chad Rule #9 - Hide the ugly things where you don’t have to look at them.

Chad Rule #10 - Use RJS helpers to reduce duplication.

Chad Rule #11 - Blocks (almost) always make it better.

Chad Rule #12 - Implicit coupling and conventions are good.

Chad Rule #13 - Master Ruby!!!

Bonus Chad Rule: Leave. If you can’t change your organization, Change your organization.

Then we had a lively discussion about outsourcing/offshoring and another one about metaprogramming.

Thanks to our sponsors and their gifts that we gave away. And here’s the obligatory Ruby code…


sponsors = {
  :relevance_llc => "Rails for Java Developers",
  :oreilly => "Rails Cookbook",
  :peepcode => "PeepCode coupon",
  :pragmatic_studio => "'I'd rather be on Rails' bumper stickers"
}

assert_equal 56, session[:attendance]

March 5, 2007. Rails. 2 Comments.