Despised Software Luminaries

This morning I spent some time thinking about how software luminaries are generally loved or hated.

I've always been confused by people who really dislike Martin Fowler. Personally, I find Martin to be quite nice, but even if I didn't I would find it hard to disregard his passion for improving software development.

Obie Fernandez is another luminary who generally evokes love or hate. I'm friends with Obie as well as people who dislike Obie. Obie detractors often ask: How can you put up with him? The question is mostly targeted at Obie's passionate communication style. I've always thought that what Obie has to say is what's important, so I don't really care how he chooses to communicate it.

As I've gotten to know an increasing number of luminaries I noticed that things don't change at the top either: several of the luminaries seem to love and hate each other.

Why is it that software luminaries elicit such passionate feelings? I believe it's because software development (at an advanced level) is art. It's hard to find developers who can agree on architecture and it's hard to find artists who can agree on the best painting of all time. There is no right answer, it's contextual and subjective.

I also believe that luminaries (unconsciously) perpetuate the disdain with their passionate personalities. For example, a Martin Fowler averse developer once told me that Martin lives in a Java only world. If you read Martin's material you know that isn't the case; however, Martin does use Java examples very often. I don't think Martin uses Java because he prefers Java, I believe that Martin is passionate about reaching as many people as possible and therefore must use a widely known language. Unfortunately, the developer didn't see it from that perspective (I believe) because he was so focused on Ruby being better than Java that he was ready to dismiss anything pertaining to Java.

Software is an art and luminaries are passionate, I don't expect either of these things to change in the near future. Thus, I expect the disdain to remain as well, but perhaps being aware of the origin of the dislike can lead to a bit more tolerance within our passionate, artistic communities.

Rails: String#constantize

Documentation

Constantize tries to find a declared constant with the name specified in the string. It raises a NameError when the name is not in CamelCase or is not initialized.

Examples

• "Module".constantize #=> Module
• "Class".constantize #=> Class

Usage
Constantize is definitely the most used String method that I utilize while metaprogramming.

Test

require 'rubygems'
require 'active_support'
require 'test/unit'
require 'dust'

unit_tests do
  class Klass
  end

  test "constantize a string representation of a class" do
    assert_equal Klass, "Klass".constantize
  end
end

Rails: String#classify

Documentation

Create a class name from a table name like Rails does for table names to models. Note that this returns a string and not a Class. (To convert to an actual class follow classify with constantize.)

Examples

• "egg_and_hams".classify #=> "EggAndHam"
• "post".classify #=> "Post"

Usage
The classify method is helpful when metaprogramming. I generally replace "strings".singularize.camelize with "strings".classify (and the classify implementation calls singularize and camelize for me).

Test

require 'rubygems'
require 'active_support'
require 'test/unit'
require 'dust'

unit_tests do
  test "singularize and camelize a string via classify" do
    assert_equal "Name", "names".classify
  end
end

Rails: String#singularize

Documentation

The reverse of pluralize, returns the singular form of a word in a string.

Examples

• "posts".singularize #=> "post"
• "octopi".singularize #=> "octopus"
• "sheep".singluarize #=> "sheep"
• "word".singluarize #=> "word"
• "the blue mailmen".singularize #=> "the blue mailman"
• "CamelOctopi".singularize #=> "CamelOctopus"

Usage
I generally use singularize when metaprogrammming to convert from a potentially plural version of a class name to something that I know can be constantized.

Test

require 'rubygems'
require 'active_support'
require 'test/unit'
require 'dust'

unit_tests do
  test "change plural word to singular word" do
    assert_equal "class_name", "class_names".singularize
  end
end

Validatable 1.6.6 released

The 1.6.6 version of Validatable was released this morning.

This was a minor release that removed custom validation assertion syntax. (http://blog.jayfields.com/2007/09/ruby-creating-custom-assertions.html)

You can replace custom validation assertions with the newly introduced validate_only instance method. The validate_only method is my latest attempt to make it easy to test model validations one at a time.

The following code should provide a decent example.

require 'rubygems'
require 'test/unit'
require 'dust'
require 'validatable'

class SampleModel
  include Validatable
  validates_presence_of :name, :address
  attr_accessor :name, :address
end

unit_tests do
  test "individual validation for name is executed" do
    instance = SampleModel.new
    instance.validate_only("presence_of/name")
    assert_equal "can't be empty", instance.errors.on(:name)
  end

  test "individual validation for address is not executed" do
    instance = SampleModel.new
    instance.validate_only("presence_of/name")
    assert_equal nil, instance.errors.on(:address)
  end
end

The validate_only method accepts an argument that is a DSL for running a single validation. The format of the DSL is "[validation type]/[key or attribute]". If the validation has a key set you should provide the key, otherwise the attribute will suffice. The documentation provides the following examples.

• validates_presence_of :name can be run with obj.validate_only("presence_of/name")
• validates_presence_of :birthday, :key => "a key" can be run with obj.validate_only("presence_of/a key")