Red Squirrel Reflections
Dave Hoover explores the psychology of software development

Dave Hoover
dave.hoover@gmail.com

Categories
All [Atom]
Craftsmanship [Atom]
Dynamic [Atom]
Intersection [Atom]
Learning [Atom]
Links [Atom]
Polyglot [Atom]
Projects [Atom]
XP [Atom]
Old Blog

Obtivian Blogs

Andy Maleh
Colin Harris
Fred Polgardy
Jim Breen
Kevin Taylor
Todd Webb
Turner King
Tyler Jennings

Archives

March 2009 (1)
January 2009 (1)
December 2008 (1)
October 2008 (3)
September 2008 (1)
June 2008 (4)
April 2008 (3)
March 2008 (1)
February 2008 (1)
August 2007 (1)
July 2007 (1)
June 2007 (1)
May 2007 (4)
April 2007 (3)
March 2007 (5)
February 2007 (6)
January 2007 (6)
December 2006 (10)
November 2006 (5)
October 2006 (8)
September 2006 (8)
August 2006 (5)
July 2006 (12)
June 2006 (7)
May 2006 (5)
April 2006 (5)
March 2006 (4)
February 2006 (2)
January 2006 (5)
December 2005 (5)
November 2005 (3)
October 2005 (3)
September 2005 (6)
August 2005 (4)
July 2005 (7)
June 2005 (14)
May 2005 (6)
April 2005 (8)
March 2005 (9)
February 2005 (11)
January 2005 (16)
Old Archives

 

Wed, 28 Feb 2007

3.weekdays.from_now

sudo gem install facets
require 'rubygems'
require 'facets/more/times'

puts 0.weekdays.from_now # Wednesday (today)
puts 2.weekdays.from_now # This Friday
puts 3.weekdays.from_now # Next Monday
puts 4.weekdays.ago      # Last Thursday
See http://facets.rubyforge.org/src/lib/facets/more/times.rb for details.

[/dynamic] permanent link

Fri, 23 Feb 2007

Ruby's Protected Access

Jamis posted yet another nugget of wisdom. This one was about Ruby's method visibility, which can be tricky for people coming to Ruby from Java or C#. Jamis left one aspect of the protected access level as an exercise for the rest of us, so I figured I'd write up an example that helps illustrate when you would use protected vs. private.
class Sibling
  def ask(sib)
    sib.tell
  end
  
  def spy_on(sib)
    sib.secret # will always complain
  end

  protected

  def tell
    secret
  end
  
  private
  
  def secret
    "Charlie tooted"
  end
end

rose  = Sibling.new
ricky = Sibling.new

begin
  puts ricky.tell
rescue
  puts "Ricky will only tell another sibling"
end

begin
  puts rose.spy_on(ricky)
rescue
  puts "Ricky complains when Rose tries to find the secret"
end

puts rose.ask(ricky) # Ricky will tell if Rose asks nicely
One of the main differences for Java developers is that objects of the same class can't see each other's private methods.

[/dynamic] permanent link

Thu, 22 Feb 2007

One Stupid Character

After helping Ryan with some routing issues in which a single character (a period) was the cause of confusion. I nearly fell off my chair laughing after this little interchange...
Ryan: yeah, the breakthrough was the dot.
      thanks for the help
      :-)
Dave: it's always one stupid character
Ryan: yes, and that character is often me

[/obtiva] permanent link

Sat, 17 Feb 2007

Relentless Simplicity with ActiveRecord

The Active Record pattern is a wonderfully simple and sufficient approach to ORM on many projects. I first used it in Java and it worked well on a small project. But in a staticly typed language like Java, using Active Record is limiting and/or awkward. It wasn't until I starting using ActiveRecord in Rails that I saw just how powerful this pattern could be when applied within a more flexible, readable language. Where nasty getter/setter hell and XML configurations are the standard in Java, we get clean, readable classes and objects in Ruby.

One of the things we do at Obtiva is provide coaching and development for Rails projects that are in trouble. I call them rescue missions. We've found that the downside to Rails' power and simplicity is that people can crank out functionality with minimal understanding of how to write maintainable, scalable software. It's only a matter of time until they hit a wall, and that's where we step in. We find people usually get into trouble with ActiveRecord when they allow themselves to write ugly code. I'm sure that there are some cases where ActiveRecord doesn't do what you need and an ugly solution is required, but I think those cases are exceptionally rare for most Rails apps.

During one of our rescue missions, I discovered a fat controller with lots of calls to find_by_sql. Again, I'm sure there are cases where this nasty method is needed, perhaps for optimization, or for some odd cases that I can't imagine (since I've never used it), but this was just plain ActiveRecord abuse. Most of us aren't aren't writing abusive ActiveRecord code, but many of us need to be more relentless in our pursuit of clean, readable, ActiveRecord usage.

We're kicking off a Rails e-commerce project so I downloaded a copy of the Rails e-commerce book to brush up on ActiveMerchant. By the way, I recommend the book to anyone coming to Rails with an immediate need to write an e-commerce site. It's also a good book for anyone wanting to see an example of TDD in Rails. But on page 175, I found a snippet of code that spurred me to write this post ... it wasn't ugly ActiveRecord code, but I would go so far as to say that it is just plain bad.

class Post < ActiveRecord::Base
  belongs_to :category  

  def self.find_all_in_category(category)
    category = Category.find_by_name(category)
    self.find :all, :conditions => "category_id = #{category.id}"
  end
  ...
end
I can read this code and understand what the author was trying to do. The method is returning all of the Posts for a given Category name. But what happens if the call to Category.find_by_name returns nil? And why would a simple thing like this require 2 separate calls to the database?
SELECT * FROM categories WHERE (categories.`name` = 'foo') LIMIT 1
SELECT * FROM posts WHERE (category_id = 1)
This is an example of not pushing hard enough to keep your code clean and simple. The first solution you can think of isn't necessarily the simplest. Don't be satisfied with anything less than elegance when you're using ActiveRecord and you'll be much better off. Here's how I would rewrite that little method:
class Post < ActiveRecord::Base
  belongs_to :category  

  def self.find_all_in_category(category_name)
    category = Category.find_by_name(category_name, :include => :posts)
    category ? category.posts : []    
  end
  ...
end
Which, thanks to the eager loading of :posts, would result in just 1 call to the database, and (to me) reads better.

[/dynamic] permanent link

Wed, 14 Feb 2007

Victoria's Journey toward Craftsmanship

I've completely neglected my apprenticeship patterns over the last year. Ruby and Rails is partly to blame for this. But the other reason is that I have an opportunity to apply Pete McBreen's ideas for the first time and, to me, that takes priority over almost anything else in my professional life, because opportunities like this don't come around very often.

Stories like the one that Victoria just related over on DevChix get me very excited about the future, and reinforce the direction the apprenticeship patterns are headed.

[/craftsmanship] permanent link

Sun, 11 Feb 2007

Growing up and Growing bigger

Working for a small software company excites me for many reasons. One of the most rewarding aspects of the 10 months that I've been working for Obtiva has been working with Tyler and watching him mature as a Rubyist. Tyler was already hacking Ruby when I met him, but since guiding him toward Rails and Ajax, Tyler has delivered some excellent work on a soon-to-be-announced Obtivian web offering. One of my favorite aspects of working with a small group of people vs. going independent is that our weaknesses and strengths are complimentary: our whole is greater than the sum of our parts. Although I did a lot of speaking and training in 2005 and 2006, one of my biggest weaknesses is (still) monologue. After road-tripping to GLSEC 2006 with Tyler last year and attending his talk, it was immediately apparent that Tyler is a gifted speaker. I'm pleased to announce that Tyler will be talking about Ruby and Rails at this month's Chicago Uniforum meeting and will be teaching our Ruby on Rails TDD Bootcamp in early March.

Even cooler still, Obtiva has just hired our first apprentice (and female), Victoria Wang. This is another important step toward establishing our software studio in Wheaton. Apprentices bring enthusiasm and an appetite for learning that inspires. On top of this, Victoria brings some other important qualities with her: excellent visual design abilities (that's her RailsConf-inspired drawing) and a non-male perspective. Welcome Victoria!

[/obtiva] permanent link


powered by blosxom